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Abstract 


DAISTS  (Data  Abstraction  Implementation,  Specification, 
and  Testing  System)  combines  a  data  abstraction  language 
containing  SIMULA-like  classes  with  algebraic  speci f ications 
and  a  library  of  test  monitoring  routines.  Each  axiom 
equates  two  sequences  of  function  compositions;  the  axioms 
are  checked  against  the  implementation  by  comparing  the 
results  of  the  function  compositions  for  a  finite  set  of 
test  points  with  a  user-supplied  equality  testing  operation. 
Inconsistencies  between  the  axioms  and  the  implementation 
are  reported  as  they  are  detected.  While  running  the  tests, 
the  system  also  monitors  statement  execution  and  expression 
evaluation.  By  insisting  that  enough  test  data  be  supplied 
to  execute  each  statement  and  axiom  and  to  vary  the  value  of 
each  sub-expression,  DAISTS  helps  users  develop  an  effective 
set  of  test  cases. 

We  have  evaluated  DAISTS  both  to  demonstrate  its  worth 
during  program  development  and  to  find  its  weaknesses.  An 
experiment  was  performed  that  compared  program  development 
with  DAISTS  against  more  conventional  program  development. 
We  showed  that  "non-expert”  programmers  could  use  formal 
specifications  in  program  development.  We  also  used  DAISTS 
in  an  implementation  of  a  simple  text  editor,  similar  to  one 
in  Kernighan  and  Plauger's  "Software  Tools"  book,  to  show 
that  DAISTS  can  effectively  be  employed  in  the  development 
of  complex  software. 
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1.  Introduction 


Program  development  remains  an  error-prone  process. 
Specifications  are  often  ambiguous  or  incomplete,  and 
validation  of  a  program's  conformance  to  its  specification 
is  not  easy  to  accomplish.  Program  proofs  are  difficult  and 
expensive  to  produce,  and  seemingly  minor  changes  in 
programs  can  require  extensive  modifications  to  the  proofs. 
Another  validation  technique,  program  testing,  is  often 
performed  by  humans  who  agree  too  readily  with  the  output  of 
the  tested  program  and  who  have  little  feel  for  how 
thoroughly  the  specification  or  program  has  been  tested. 
These  problems  are  magnified  during  the  later  stages  of  the 
software  life  cycle.  Since  specifications,  programs,  and 
test  data  are  usually  separate  entities,  each  can  be  altered 
without  regard  to  the  others. 

We  have  implemented  DAISTS  (Data  Abstraction 
Implementation,  Specification,  and  Testing  System)  which 
combines  a  data  abstraction  language  containing  SIMULA-like 
classes  with  a  formal  specification  and  a  library  of  test 
monitoring  routines.  Inconsistencies  between  the 
specification  and  the  implementation  are  reported.  The 
system  also  monitors  statement  execution  and  expression 
evaluation,  insisting  that  enough  test  data  be  supplied  to 
execute  each  statement  and  to  vary  the  value  of  each  sub¬ 
expression.  It  is  this  combination  of  the  software 
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technologies  of  formal  specifications,  coverage  metrics,  and 
high-level  implementation  languages  that  makes  DAISTS 
interesting.  We  have  also  evaluated  DAISTS  both  to 
demonstrate  its  worth  during  program  development  and  to  find 
its  weaknesses. 

The  next  chapter  discusses  various  specification  and 
validation  techniques,  and  their  implications  and  .tuts. 
Chapter  three  describes  our  implementation  of  DAI ST  and 
the  fourth  and  fifth  chapters  discuss  our  evaluat  *  of 
DAISTS:  an  experiment  comparing  program  developing  . w  in 
DAISTS  against  more  conventional  strategies,  and  a  case 
study  of  the  implementation  of  a  simple  text  editor  with 
DAISTS.  The  sixth  chapter  summarizes  our  experiences  with 
this  tool,  and  offers  some  suggestions  for  further  research. 


i 
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2 .  Background 

DAISTS  relies  on  the  ideas  of  specification  techniques, 
testing  theory,  correctness  oracles,  and  test  data 
completeness  criteria.  We  survey  the  state  of  the  art  in 
these  areas  so  that  the  design  decisions  for  DAISTS  can  be 
evaluated. 

2.  jL.  Specifications 

Good  specifications  are  restrictive  enough  to  ensure  that  no 
unacceptable  implementations  satisfy  them  and  general  enough 
so  that  they  preclude  no  acceptable  implementations.  They 
are  both  concise  and  plain  so  that  their  correspondence  to 
intuitive  ideas  can  be  easily  judged. 

Specifications  can  be  given  in  a  variety  of  notations 
that  differ  in  their  formality.  [Liskov  and  Zilles  75] 
review  several  specification  techniques  and  give  criteria 
for  evaluating  them.  They  describe  five  specification 
techniques:  "fixed  discipline,"  "arbitrary  discipline," 
"state  machine  model,”  "axiomatic  descriptions,"  and 
"algebraic  definitions."  These  techniques  fall  into  two 
classes:  operational  techniques  (specifying  how  to  implement 
the  objects) ,  and  definitional  techniques  (specifying  the 
properties  of  the  objects  without  suggesting 
implementations).  We  would  categorize  their  "fixed 
discipline,"  "arbitrary  discipline,"  and  "state  machine 


model"  techniques  as  operational  and  their 


axiomatic"  and 


"algebraic"  techniques  as  definitional. 

The  following  specification  fragment  is  operational 

because  it  describes  the  implementation  of  the  data  type 

stack  in  terms  of  sequences  of  integers. 

Pop(S)  *  i_f  IsEmptySequence  (S) 
then  S 
else  Rest(S) 

Rest(S)  accepts  a  sequence  S  and  returns  a  new  sequence  that 

is  the  same  as  the  original  except  that  the  first  element 

has  been  removed.  (This  definition  assumes  that  the  top  of 

the  stack  is  at  the  front  of  the  sequence.)  Anv  attempt  to 

implement  a  stack  with  a  different  representation  will 

require  two  conceptual  translations:  one  from  the  chosen 

representation  into  sequences,  and  another  from  sequences  to 

stacks.  The  corresponding  fragment  of  a  definitional 

specification  only  shows  the  interaction  of  the  functions  of 

the  type,  and  does  not  give  any  information  that  might 

predispose  an  implementor  to  a  specific  concrete 

representation . 

Pop (EmptyStack)  *  EmptyStack 

Pop  (Push  (S  ,X)  )  *  _if  Depth  (S)  <  DepthLimit 

then  S 
else  Pop(S) 

Operational  techniques  seem  to  have  the  flavor  of 
programming  and  to  suffer  most  of  the  same  problems: 

representational  dependencies,  untreated  boundary  cases,  and 
arbitrary  details  such  as  the  order  in  which  conditions  are 
tested.  The  definitional  techniques,  because  they  are  less 


procedural,  allow  more  freedom  in  choosing  the 
implementation.  [Guttag  75]  has  suggested  a  method  for 
writing  specifications  thr  *■  ensures  that  boundary  cases  are 
explicitly  treated. 

2.1.1,.  Using  formal  specifications 

There  is  little  incentive  for  writing  formal  specifications 
unless  there  is  some  way  to  demonstrate  the  consistency  of 
the  specifications  and  an  implementation.  Most  of  the  work 
done  in  exhibiting  this  consistency  uses  the  methods  of 
program  verification  with  little  or  no  machine  assistance 
[Hoare  1972],  [Wegbreit  and  Spitzen  1976],  [Wulf  et  al. 

1976] .  The  "pure  algebraic"  approach  [ADJ  1978],  [Guttag 

1977] ,  [Zilles  1975]  avoids  assertion-based  correctness  and 
implementation.  The  AFFIRM  system  [Musser  79]  and  the  OBJ 
system  [Goguen  and  Tardo  79]  provide  mechanisms  for  the 
symbolic  manipulation  of  algebraic  specifications.  In  the 
OBJ  system,  algebraic  axioms  are  used  as  rewriting  rules  to 
"execute"  trial  expressions,  but  there  is  no  independent 
implementation  language.  AFFIRM  joins  axiom  rewriting  with 
conventional  verification  of  Pascal  programs  that  implement 
data  types.  The  user  interacts  with  the  AFFIRM  system  to 
produce  verification  conditions  and  guides  the  system  in 
proving  them. 


While  both  systems  can  be  used  to  prove  new  properties 
of  specified  objects  and  to  exercise  specifications  before 


implementation,  comparing  algebraic  specifications  to 
implementations  with  either  system  is  difficult.  The  proofs 
produced  with  the  AFFIRM  system  require  complex  assertions 
to  describe  the  implementation  and  are  valid  only  for  a 
particular  implementation  so  that  a  change  to  the 
implementation  may  require  a  new  proof. 


2.2.  Testing 


In  contrast  to 

proof  methods  that  attempt 

to 

help 

human 

beings 

avoid 

mistakes,  testing  methods 

seek 

to 

expose 

errors . 

Testing  is  machine-intensive,  and 

good 

tests  are 

those  that  fail — a  successful  test  (i.e.,  one  that  exposes 
no  errors)  is  of  dubious  value.  Path  testing  [Howden  76], 
symbolic  execution  [Clarke  76] ,  domain  testing  [White  and 
Cohen  80] ,  program  mutation  [DeMillo,  Lipton,  and  Sayward 
78] ,  expression  monitoring  [Hamlet  77] ,  and  dual  testing 
[Panzl  81]  have  all  been  suggested  as  testing  strategies. 
Each  testing  strategy  includes  an  oracle  to  determine  if  the 
program  output  is  correct  for  the  test  input  and  structural 
criteria  to  judge  the  sufficiency  of  the  test  data. 
Structural  criteria  improve  the  confidence  obtained  from  a 
successful  test  by  excluding  the  "success"  in  which  a 
program  bug  lurks  in  untested  code.  The  simplest  such 
criteria  is  that  every  statement  of  code  be  invoked  by  at 
least  one  test  point. 
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2.2.1.  Path  analysis  testing 

A  path  through  a  program  corresponds  to  a  possible  flow  of 
control  in  the  program.  The  subset  of  the  program's  domain 
that  causes  a  particular  path  to  be  executed  is  the  path's 
oath  domain.  The  function  computed  by  the  sequence  of 
operations  in  a  path  is  its  path  computation.  The  path 
analysis  testing  strategy  divides  the  program  domain  into 
subsets  that  correspond  to  the  path  domains  and  generates 
the  set  of  test  data  by  selecting  one  element  from  each 
non-empty  subset.  This  strategy  breaks  down  when  the 
program  contains  a  loop  based  on  its  input  variables  because 
the  number  of  paths  (and  therefore  the  number  of  path 
domains)  is  potentially  infinite. 

There  are  three  approximations  to  path  testing  to 
circumvent  this  problem:  level-N  path  testing ,  branch 
testing ,  and  statement  testing.  Level-N  path  testing 
systems  only  consider  paths  containing  up  to  N  (an 
arbitrarily  fixed  number)  iterations  through  the  loops 
comprising  the  path.  Branch  testing  criteria  require  that 
enough  test  data  be  supplied  so  that  every  branch  of  a 
program  is  executed  at  least  once.  Even  a  program  with  an 
infinite  number  of  paths  has  only  a  finite  number  of 
branches.  The  completeness  of  a  set  of  tests  for  the  branch 
testing  criteria  does  not  guarantee  correctness,  but  branch 
testing  completeness  is  a  necessary  criteria  for  correctness 


in  that  it  is  impossible  for  a  set  of  tests  to  expose  errors 

in  program  branches  that  it  does  not  force  to  be  executed. 

Early  testing  systems  (Sites  71] ,  [Stucki  73]  implemented 

statement  testing  by  constructing  an  execution  histogram 

indicating  statements  that  had  not  been  executed.  While 

branch  testing  requires  that  test  data  include  values  for 

which  while  and  i^  statements  execute  their  statement  lists 

zero  times,  the  statement  testing  criteria  is  satisfied 

without  such  values  among  the  test  data.  For  example,  when 

testing  the  following  loop: 
while  I  >  0  do 

X  :«  (X  +  I)  /  (I  -  5) 

I  I  -  1 

end 

the  statement  testing  criteria  is  satisfied  with  the  single 
test  point  (1*2) .  Branch  testing  would  require  an 
additional  test  point  that  would  execute  the  loop  body  zero 
times,  but  would  be  satisfied  with  the  two  test  points  (1*0) 
and  (1*2) .  Level  2  path  testing  needs  the  test  points 
(1*0),  (1*1),  and  (1*2)  to  execute  the  loop  body  zero  times, 
once  and  twice  respectively.  These  criteria  fail  to  reveal 
the  problem  with  division  by  zero  when  I  has  the  value  5. 
The  error  would  be  exposed  by  path  testing  whenever  the 
iteration  threshold  is  greater  than  4. 


2.2.2 .  Symbolic  execution 

Symbolic  execution  systems  [Clarke  76] ,  [King  76]  are 
similar  to  path  testing  systems.  A  path  is  selected  (either 
automatically  or  interactively  by  the  user) ,  and  the  system 
symbolically  executes  the  program  along  the  chosen  path  by 
collecting  symbolic  representations  of  the  output  variables 
and  path  constraints  expressed  in  terms  of  the  input 
variables.  By  examining  the  union  of  these  constraint 
expressions,  the  user  is  expected  to  determine  if  the  path's 
computation  is  correct,  and  if  the  path  constraints  are  the 
ones  that  were  expected.  Some  systems  attempt  to  "solve"  or 
reduce  the  path  constraints  and  use  these  solutions  to 
generate  test  data  for  the  paths,  proceeding  as  in  the  path 
testing  strategy.  These  systems  can  also  be  used  to 
generate  test  data  that  meet  criteria  other  than  program 
correctness:  that  array  indexing  expressions  stay  in  bounds, 
that  variables  will  vary  with  the  input,  that  division  by 
zero  is  avoided,  and  that  all  branches  in  a  program  are 
feasible. 

For  example,  let  us  consider  the  sample  program  [Clarke 

76]  : 

read  A,B 

X  :»  A  *  B  +  2 

if  X  >  100  then  X  :*  100  -  X 

X  :«  X  -  50 

if  X  <  0  then  X  :*  0 

print  X 

If  the  user  specifies  the  four  paths  "true  true",  "true 
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false",  "false  true",  and  "false  false"  (a  path  being 
determined  by  the  value  of  the  conditional  expressions  of 
the  _if  statements)  ,  symbolic  execution  (with  simplified 
constraints)  produces: 


Path 

true  true 
true  false 
false  true 
false  false 


Constraints 

a*b>98 

a*b>98,  a*b<*48 
a*b<48 

a*b<»98,  a*b>»48 


Result 
x  *  0 

infeasible 
x  *  0 

x  •  a*b-48 


Symbolic  execution  systems  have  the  same  problems  with 
loops  that  path  testing  systems  have.  Additionally,  the 
symbolic  expressions  produced  could  be  so  complex  that  it 
may  not  be  easy  for  the  programmer  to  decider  if  the  path 
computations  are  correct. 


2.2.3.  Domain  testing 


[White  and  Cohen  80] 

presented  a 

testing 

strategy 

that 

detected  errors  in 

the  control 

flow  of 

a  program 

by 

examining  the  program 

's  performance 

on  test 

points  near 

the 

boundaries  of  its 

path  domains. 

Their 

domain  testing 

strategy  selected  two  points  from  each  path  domain  boundary, 
and  a  third  point  near  the  domain  boundary  but  outside  the 
domain  being  examined.  They  concluded  that  if  the  program 
executed  correctly  for  all  three  points,  then  the  location 
of  the  boundary  must  have  been  correct  (or  at  least  off  by 


no  more  than  the  distance  from  the  boundary  to  the  third 
point) .  Their  implementation  of  this  technique  was  limited 
to  programs  containing  no  arrays,  and  whose  path  predicates 
were  all  linear.  Furthermore,  it  required  the  program 
domain  to  be  continuous,  and  was  vulnerable . to  the  problems 
of  coincidental  correctness  (when  a  specific  data  point 
follows  an  incorrect  path,  yet  coincidentally  computes  the 
correct  value) ,  and  infinite  numbers  of  path  domains  (for 
programs  containing  input-variable-bounded  loops) . 

2.2.4.  Mutation  systems 

[DeMillo,  Lipton,  and  Sayward  78]  found  that  complex  errors 
in  programs  were  often  coupled  to  simpler  ones  and  that 
systematic  searches  for  common  simple  errors  could  often 
uncover  complex  ones.  Their  testing  strategy  mutates  the 
original  program  (the  one  being  tested)  by  a  single  token 
and  then  runs  both  the  original  program  and  the  mutant  on 
the  same  test  data.  If  the  mutant  program  yields  the  same 
computations  as  the  original,  then  either  the  mutation 
performed  was  a  trivial  one  (e.g.,  the  programs  are 
equivalent) ,  or  the  test  data  was  not  sensitive  enough  to 
detect  the  mutation.  A  mutant  is  considered  "dead"  if  it 
contains  detectable  errors  and  "live"  if  the  test  data  does 
not  distinguish  it  from  the  original.  Test  data  that  leaves 
no  live  mutants  (or  only  mutants  that  are  equivalent  to  the 
original)  are  considered  adequate  *n  that  either  (1)  the 
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program  is  correct  or  (2)  it  contains  an  unexpected  error 
which,  by  the  coupling  effect,  can  be  expected  to  occur 
infrequently  if  the  mutants  are  carefully  constructed.  The 
mutation  testing  strategy  requires  the  user  to  provide 
enough  test  data  to  expose  commonly-made  errors. 


By  way  of  example,  consider  the  following  program  and 
one  of  its  mutants: 

Mutant 


Original 

subroutine  Max (A,N,R) 
integer  A(N),I,N,R 
R*i" 

do  3  I*  2 ,N, 1 
3  if (A(I) «2t.A(R) )R*I 
return 
end 


subroutine  Max(A,N,R) 
integer  A(N) ,I,N,R 

do  3  I*  2  ,N ,  1 
3  if  (I.gMt.A{R)  )R=I 
return 
end 


In  the  mutant,  the  reference  to  "A(I) "  has  been  replaced 
with  "I".  When  tested  with  the  test  data  (N=3,  A(1)=0, 
A(2)»-4,  A(3)*3),  the  mutant  produces  the  same  value  as  the 
original  program.  In  fact,  any  test  data  that  has  the 
largest  value  in  the  array  A  stored  in  its  last  cell  will 
fail  to  discriminate  between  the  programs?  any  other  test 
data  will  expose  the  error  in  the  mutation.  Considered  by 
itself,  testing  this  mutant  has  little  merit,  but  generating 
all  the  mutations  in  which  one  variable  reference  has  been 
replaced  by  another  and  finding  test  data  that  eliminates 
them  will  catch  many  variable-reference  errors  in  the 
original  program. 
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This  testing  strategy  was  used  to  develop  a  set  of  test 
data  that  left  only  19  live  mutants  out  of  over  22,000 
mutations  of  a  27-statement  FORTRAN  routine  that  found  the 
largest  integer  in  an  array.  The  remaining  live  mutants 
were  shown  to  be  equivalent  to  the  original  (correct) 
routine. 

2.2.5.  Compiler-based  testing 

[Hamlet  77]  implemented  a  system  that  allowed  a  user  to  give 
input-output  pairs  for  specifications  of  functions  and  used 
these  pairs  as  data  points  to  test  the  functions.  As  the 
system  tested  the  behavior  of  the  program  (against  the 
input-output  pairs) ,  it  recorded  the  history  of  all  the 
values  in  the  program.  After  execution,  the  system  examined 
the  expression  history  and  tried  all  shorter  expressions  to 
see  if  the  test  data  justified  the  complexity  of  each 
expression  in  the  program.  If  an  equivalent  expression 
could  be  found  that  was  "shorter"  than  the  one  in  the 
program's  text  or  if  the  expression  stayed  constant,  then 
his  system  reported  the  shorter  expression,  and  the  user 
(was  to  have)  supplied  more  input-output  pairs  that  would 
justify  the  program's  textual  complexity.  His  system  was 
limited  to  testing  integer  functions  of  single  integer 
parameters. 
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2.2.6.  Dual  Testing 

Writing  two  implementations  for  the  same  problem,  and  using 
each  to  check  the  output  of  the  other  on  randomly  selected 
points  from  the  program  domain,  has  also  been  suggested 
[Panzl  81] ,  [Weyuker  80] .  Panzl's  Dual  test  driver 
generates  random  test  cases  under  the  control  of  a  formal 
specification  of  the  problem's  input  domain,  supplies  the 
test  cases  to  each  program,  and  compares  the  outputs  of  the 
programs.  However,  any  system  based  on  testing  on  random 
points  from  the  program  domain  is  unlikely  to  test  boundary 
conditions,  where  many  errors  occur  [Goodenough  and  Gehart 
75]  . 


2. 2,. 2*  Oracles 

Even  if  a  set  of  test  data  meets  any  of  the  structural 
criteria  described  above,  the  programmer  must  still 
determine  if  the  program  is  producing  the  correct  results  on 
the  test  data.  The  process  by  which  a  judgement  is  rendered 
on  the  correctness  of  test  results  is  often  call  an  oracle . 
Two  "oracles"  are  available:  the  programmer  and  the 
specification.  Most  testing  systems  rely  on  some  variation 
of  the  programmer  as  the  oracle  —  either  by  having  the 
programmer  pre-compute  the  output  value  for  each  input  test 
point  or  by  providing  the  programmer  with  some 
representation  of  the  results  and  asking  him  to  check  that 
the  desired  function  was  computed.  In  practice,  this  human 
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oracle  is  frequently  too  willing  to  agree  with  the  program. 
The  results  of  a  computation,  even  presented  symbolically, 
can  be  too  complicated  for  a  human  to  judge  reliably 
[Weyuker  80] . 

Specification-based  oracles,  such  as  input-output 
pairs,  are  less  easily  satisfied  but  limited,  encoding  only 
a  part  of  a  program's  behavior.  Testing  based  on  pure 
input-output  pairs  has  little  to  recommend  it;  since  any 
test  is  finite,  it  could  be  met  by  a  program  written  as  a 
case  statement  covering  the  given  pairs  and  otherwise 
entering  a  never-ending  loop.  Another  drawback  to  input- 
output  pairs  is  that  the  output  must  be  calculated  and 
represented  in  a  concrete  form.  Writing  input-output  pairs 
for  structured  objects  requires  both  knowledge  of  their 
representation  and  considerable  hand  simulation  (e.g.,  to 
express  the  result  of  inserting  a  new  identifier  into  a 
hash-coded  symbol  table) . 

2.3.  Testing  theory 

While  a  successful  test  that  reveals  no  errors  increases  our 
confidence  in  the  program,  it  is  of  little  theoretical 
value.  [Howden  76]  provides  us  with  the  following  theorems: 
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Theorem :  Suppose  that  P  is  a  program  for  computing 
a  function  F  with  domain  D.  There  exists  a  finite  subset 
T  of  D  which  can  be  used  to  determine  the  correctness  of 
P,  i.e.  there  exists  a  finite  set  T  <a  subset  of>  D  such 
that: 

P(x)  =  F(x)  for  all  x  in  T  =>  P(x)  =  F(x)  for  all  x  in  D. 


Theorem:  There  exists  no  computable  procedure  H 
which,  given  an  arbitrary  program  P  and  function  F  with 
domain  D,  can  be  used  to  generate  a  nonempty  finite  set 
T  <a  subset  of>  D  such  that: 

P(x)  *  F (x)  for  all  x  in  T  =>  P{x)  =  F(x)  for  all  x  in  D. 

The  first  theorem  tells  us  that  if  a  program  is  not 
correct,  then  there  must  be  some  element  of  the  program's 
domain  that  shows  the  program  is  not  correct.  The  second 
theorem  tells  us  that  there  is  no  general  procedure  for 
finding  those  elements  that  show  the  program  is  incorrect. 
Thus,  it  is  not  possible  to  design  an  automatic  system  that 
can  guarantee  detection  of  all  of  the  errors  in  any  program. 
However,  while  we  know  that  no  general  procedure  exists,  the 
theory  does  not  rule  out  our  being  able  to  manufacture  a 
system  that  could  "reliably"  find  the  elements  that  can  be 
used  to  demonstrate  specific  errors.  Again,  [Howden  76] 
provides  these  definitions: 
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Definition:  Suppose  P  is  a  program  for  computing  a 
function  F  whose  domain  is  the  set  D.  Let  T  be  a  subset 
of  D.  T  is  a  reliable  test  set  for  P  if: 

P(y)  3  F (x)  for  all  x  in  T  =>  P(x)  =  F(x)  for  all  x  in  D. 


Definition :  Suppose  P  is  a  program,  and  that  H  is  a 
strategy  for  generating  subsets  Tl,  T2,  . . . ,  Tn  of  D 
such  that  any  set  T  which  can  be  constructed  by  taking 
one  element  from  each  Ti  is  a  reliable  test  set  for  P. 

Then  H  is  a  reliable  test  strategy  for  P. 

Briefly,  that  a  test  set  is  reliable  means  that  if  the 
program  works  for  all  of  the  elements  in  the  test  set,  then 
it  will  work  on  any  element  of  the  program's  domain.  This 
can  be  achieved  in  some  cases  by  including  all  of  the 
program's  domain  in  the  test  set  (exhaustive  testing) .  A 
routine  to  sum  the  initial  two  cards  in  a  blackjack  hand 
could  be  tested  on  all  2652  combinations  of  cards.  Other 
reliable  test  sets  are  significantly  smaller  than  the  entire 
program  domain.  A  reliable  test  strategy  is  one  that  always 
builds  reliable  test  sets.  Again,  one  obviously  reliable 
test  strategy  for  programs  with  finite  domain  is  to  generate 
the  testset  containing  all  of  the  program's  domain  (by 
putting  each  element  of  the  domain  into  its  own  subset  Ti, 
and  then  choosing  (the)  one  element  from  each  Ti) . 
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2^.4^.  Evaluating  testing  strategies 

Making  use  of  this  theory  in  the  evaluation  of  testing 
systems  is  difficult.  When  Howden  examined  a  set  of  11 
programs  with  well  known  errors  that  had  appeared  in 
[Kernighan  and  Plauger  74],  he  reported  [Howden  76]  that 
"path  testing  was  found  to  be  reliable  or  almost  reliable 
for  about  65  percent  of  the  errors."  Symbolic  execution  was 
found  to  result  in  a  10-20%  increase  in  reliability  of  error 
detection  over  similar  testing  done  on  actual  data  values  in 
[Howden  77] .  Experimental  evidence  on  the  development  of  4 
programs  with  Panzl's  DUAL  testing  system  has  shown  that  it 
increased  development  costs  77%,  but  drastically  reduced  the 
residual  errors  in  programs  from  69  to  2. 
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3.  DAISTS 


We  have  built  a  system  called  DAISTS  (Data  Abstraction 
Implementation,  Specification,  and  Testing  System)  which 
combines  a  high-level  implementation  language,  an 
independent  formal  specification  notation,  and  some  test 
data  coverage  measures.  The  implementation  language  allows 
a  programmer  to  define  types  via  a  class  construct  similar 
to  that  of  SIMULA  67  (Dahl  et  al.  70],  DAISTS  transforms 
algebraic  specifications  [Guttag  77]  into  test  drivers  for 
the  implementation.  The  specifications  and  a  user-defined 
concrete  equality  function  provide  an  oracle  for  judging  the 
correctness  of  values  returned  by  the  functions  of  the 
implementation  on  user  inputs.  Test  data  coverage  criteria 
require  that  each  statement  in  the  program  be  executed  and 
each  expression  take  on  multiple  values  for  a  successful 
test  to  be  completed.  Two  implementations  of  DAISTS 
currently  exist:  one  for  the  UNIVAC  1100  and  the  other  for 
the  VAX  11/780. 

The  skeletal  structure  of  a  DAISTS  module  is  shown 
below : 

.  implementation  module 
axioms 

.  algebraic  axioms  describing  the  module 
testpoints 

.  declaration  and  initialization  of  test  values 
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testsets 


.  sets  of  test  points  to  be  used  with  each  axiom 
start 

3^.  Implementation  language 

The  implementation  language  of  DAISTS  is  SIMPL-D  [Gannon  and 
Rosenberg  1979],  a  member  of  the  SIMPL  family  [3asili  1976] 
with  features  that  permit  the  declaration  of  abstract  data 
types.  This  language  has  only  modest  facilities  compared  to 
CLU  [Liskov  and  Zilles  1974]  or  Mesa  [Geschke  et  al.  1977] ; 
there  are  no  features  that  support  exception  handling  or 
non-determinism.  Furthermore,  the  interaction  of 
implementations  and  axioms  in  DAISTS  forces  further 
restrictions  on  the  use  of  the  implementation  language 
(e.g.,  side  effects  are  prohibited). 

SIMPL-D  class  declarations  define  new  types  that  may 
subsequently  be  used  in  object  declarations.  The  interior 
of  a  class  is  a  series  of  variable  declarations  (the 
representation)  followed  by  a  series  of  procedure 
declarations  (the  body) .  Including  the  names  of  procedures 
in  the  class  heading  makes  the  procedures  visible  outside 
the  class.  The  appearance  of  the  reserved  word  assign  in 
the  operation  list  enables  the  assignment  operation  (:=)  to 
be  applied  to  objects  of  this  class  type.  As  with 
primitive-type  objects,  applying  the  assignment  operation  to 
class  objects  results  in  the  value  of  the  right  operand 
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being  copied  to  the  location  of  the  left  operand. 

When  a  unit  of  scope  containing  the  declaration  of  a 
class  object  is  executed,  a  new  copy  of  the  object  is 
allocated  and  initialized.  Users  generally  view  class 
objects  as  indivisible  entities;  their  components  cannot  be 
accessed  outside  the  class  declaration.  Inside  the  class, 
these  objects  may  be  viewed  as  structures  containing  more 
primitive  objects.  Statements  in  the  body  of  a  class  can 
access  the  components  of  a  class  object  using  a  period 
notation  similar  to  that  of  PL/I  or  Pascal. 

We  present  here  a  module  containing  the  definition  of 
the  data  type  "bounded"  Stack.  The  operations  available  on 
Stack  objects  are  listed  in  the  class  heading;  the  code 
implementing  these  operations  (except  for  the  system-defined 
assignment  operation)  is  found  in  the  class  body.  An  array 
of  EltType  (e.g.,  integer)  values  and  an  index  of  the  last 
value,  StackTop,  form  the  representation  for  Stack  objects. 
Each  time  a  Stack  object  is  bound  to  storage,  space  is 
reserved  for  the  array  and  integer  index.  "Push"  constructs 
a  new  stack  object  by  placing  a  new  value  on  top  of  a  copy 
of  its  input  parameter  and  returns  the  modified  copied 
object  without  altering  its  parameters.  Attempts  to  push  a 
new  value  on  a  full  Stack  object  are  ignored.  "Pop"  removes 
a  value  from  a  nonempty  Stack  object  and  has  no  effect  on 
empty  Stack  objects.  "Top"  returns  the  top  value  of  a  Stack 
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object,  without  altering  it,  "Top"  returns  Undefined  (in 
the  example  0)  if  it  is  applied  to  an  empty  Stack  object. 
"NewStack"  returns  as  its  value  an  empty  Stack  object. 
"Depth"  can  be  used  to  discover  the  number  of  values  in  a 
Stack  object  and  "DepthLimit"  gives  the  upper  bound  on  the 
number  of  values  that  can  be  placed  in  any  Stack  object. 
"StackEqual"  judges  two  stack  objects  to  be  equal  if  they 
contain  the  same  number  of  elements,  stored  in  the  same 
order.  A  definition  of  "StackEqual"  must  be  included  in  the 
implementation  because  DAISTS  invokes  it  to  judge  the 
equality  of  Stack  objects. 

class  Stack  =  Push,  Pop,  Top,  Empty,  NewStack, 

StackEqual,  Depth,  DepthLimit,  assign 

/*  macro  definitions  to  control  representation  */ 
define  EltType  =  '*int'* 
define  Undefined  =  "O' 
define  StackSize  =  '20' 

/*  representation  */ 

unique  EltType  array  Values (StackSize) 

/*  Remember  that  this  array  is  0 . .StackSize-1  */ 
unique  int  StackTop 

/*  body  containing  operation  definitions  */ 

Stack  f unc  NewStack 

Stack  Result  /*  local  variable  of  type  stack  */ 

Result. StackTop  :=  -1 
return (Result) 

Stack  func  Push (Stack  S,  EltType  Elt) 

Stack  Result 

if  S. StackTop  +  1  *  StackSize 
then 

return (S)  /*  return  stack  unchanged  */ 

end 

Result  :■  S  /*  copy  to  avoid  side  effects  */ 

Result . StackTop  :=  Result . StackTop  +  1 
Result. Values (Result. StackTop)  :*  Elt 
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return (Result) 

Stack  func  Pop(Stack  S) 

Stack  Result 
if  Empty (S) 
then 

return (S) 

end 

Result  : *  S  /*  copy  to  avoid  side  effects  */ 
Result. StackTop  Result . StackTop  -  1 
return (Result) 

EltType  func  Top (Stack  S) 
if  Empty (S) 
then 

return (Undefined) 

end 

return (S. Values (S . StackTop) ) 

Bool  func  Empty (Stack  S) 
return (S. StackTop  *  -1) 

Bool  func  StackEqual (Stack  P,  Stack  Q) 
int  I 

if  Depth (P)  *  Depth (Q) 
then 

I  :=  P. StackTop 

while  I  >=  0  do  /*  compare  all  elements  */ 
if  P. Values (I)  <>  Q. Values (I) 
then 

return (False) 

end 

I  :a  I  -  1 
end 

return (True) 

end 

return (False) 

int  func  Depth (Stack  S) 

return (S. StackTop  +  1) 

int  func  DepthLimit 

return (StackSize) 

endclass  /*  end  of  declaration  of  class  Stack  */ 
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2-2.  Specifications 

Since  we  are  interested  in  comparing  the  consistency  of 
specifications  and  implementations  mechanically,  a  formal 
specification  technique  is  essential.  If  the  specification 
is  operational,  it  is  likely  to  be  similar  to  the 
implementing  code.  We  have  therefore  chosen  a  version  of 
the  algebraic-axiom  technique,  whose  character  is 
nonprocedural.  Thus  even  though  the  same  programmer  might 
write  both  specification  and  code,  it  is  unlikely  that  one 
will  borrow  much  from  the  other.  This  independence  makes 
the  task  of  comparison  more  difficult  but  increases  the 
significance  of  a  successful  consistency  check. 

The  primitives  of  the  specification  language  include 
boolean  and  integer  constants,  free  variables,  equality 
operators,  other  boolean  and  integer  operators,  and 
functional  composition.  Axioms  equate  two  expressions;  the 
first  expression  is  generally  a  function  composition,  and 
the  second  expression  is  a  combination  of  primitives  and 
conditional  expressions  like  those  of  ALGOL  60.  Each  axiom 
presented  to  the  DAISTS  processor  is  named  and  has  a  list  of 
the  names  and  types  of  the  free  variables  used  in  the  axiom. 
A  familiar  axiom  of  bounded  stacks  appears  as: 

Pop2(Stack  S,  EltType  I): 

Pop  (Push  (S ,  I) )  *  i_f  Depth  (S)  =  DepthLimit 

then  Pop(S) 
else  S; 

This  axiom  tells  us  that  the  result  of  popping  a  Stack  S 
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after  pushing  a  new  value  I  onto  S  is  the  same  as  either  the 
value  of  the  object  obtained  by  popping  S,  or  the  value  of 
the  original  Stack  S  otherwise.  (If  S  already  contained  the 
maximum  number  of  values  before  the  push,  attempts  to  push  a 
new  value  on  S  would  be  ignored.) 


A  set  of  axioms  for  bounded  stacks  appears  below: 
Emptyl : 

Empty (NewStack)  *  True; 

Empty2(Stack  S,  EltTvpe  I): 

Empty (Push (S, I) )  *  False; 

Topi: 

Top (NewStack)  =  Undefined; 

Top2 (Stack  S,  EltType  I); 

Top(Push(S,I)  )  *  i_f  Depth(S)  =  DepthLimit 

then  Top(F) 
else  I; 

Pop! : 

Pop (NewStack)  =  NewStack; 

Pop2(Stack  S,  EltType  I): 

Pop (Push (S, I) )  *  jj[  Depth (S)  *  DepthLimit 

then  Pop ( S ) 
else  S; 

Depthl : 

Depth (NewStack)  =  0; 

Depth2 (Stack  S,  EltType  I): 

Depth  (Push  (S,  I)  )  *  i_f  Depth(S)  *  DepthLimit 

then  Depth  (S) 
else  Depth (S)  +  1; 

EqualO : 

StackEqual (NewStack , NewStack)  ■  True; 

Equall(Stack  ?,  Stack  Q,  EltType  I): 

StackEqual (P, Push (Q , I) )  * 

if  StackEqual (P, NewStack) 
then  False 
else 


if  Depth (Q)  <  DepthLimit 
then 

If  Top (P)  -  T 

then  StackEqual (Pop (P) ,Q) 
else  False 

else  StackEqual (P ,Q) ; 

•  Supplying  Test  Data 

The  testpoints  section  looks  like  a  procedure,  complete  with 
declarations  and  executable  statements.  This  section  allows 
users  to  build  objects  to  be  referenced  in  the  subsequent 
testsets  section  of  the  program.  An  object  that  is 
expensive  to  construct  can  thus  be  used  in  testing  several 
axioms  without  repeating  its  construction. 


Construction  of  an  initial  set  of  test  data  for  bounded 
stacks  is  straightforward.  The  obvious  test  points  are 
selected;  NewStack  (an  empty  stack),  Part  (a  partially  full 
stack)  ,  and  Full  (a  full  stack) .  Objects  containing  these 
values  are  constructed  below. 
testpoints  /*  to  be  used  in  the  test  sets  */ 

Stack  Part,  /*  a  par tially-full  stack  */ 

Full  /*  a  full  stack  */ 

int  I 

Part  ;=*  Push  (Push  (Push  (NewStack ,  1)  ,  2)  ,  3) 

Full  :*  Part 

I  :  =  4 

while  I  <*  DepthLimit  do 
Full  :*  Push (Full, I) 

I  :»  I  +  1 
end 

The  testsets  section  of  the  program  contains  a  list  of 
axiom  names  with  values  to  be  substituted  for  the  free 
variables  of  the  axioms.  Test  sets  need  not  be  given  for 
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axioms  without  free  variables  (e.g.,  Emptyl,  Topi,  Popl,  and 
Depthl) ;  the  calls  to  test  them  are  generated 
automatically. 

The  tests  for  our  bounded  stack  example  appear  below. 
testsets  /*  to  "test"  the  axioms  */ 

Empty2:  (Part, 7) ,  (NewStack , 1) ; 

Too2,  Pop2,  Depth2:  /*  Note  how  these  share  test  data.  */ 
(NewStack, 1) ,  (Part, 2),  (Full, 3), 

(Push (Pop (Full) ,32) ,4) ; 

Equall:  (Part, Part, 8) ,  (Push (Part, 2) , Part, 2) , 

(NewStack, Part, 3) ,  (Full, Full, 4) , 
(Push(Push(Push(Push(NewStack,2) ,2) ,3) ,2) , Part, 2)  , 
(Part, NewStack, 3) , 

(Push (Pop (Full)  ,8) ,Push (Pop (Full) ,7)  ,6)  ; 

3.4.  DAI  STS'*  oracle 

The  axioms  and  equality  functions  serve  as  DAISTS^  oracle; 
the  oracle  is  unlimited  in  that  any  test  case  presented  can 
be  judged.  The  tests  are  turned  into  calls  on  the  axioms, 
which  act  as  driver  programs  for  the  implementation 
functions.  The  left  and  right  sides  of  an  axiom  return 
values  that  are  judged  for  equality  by  an  appropriate 
equality  function  (e.g.,  StackEqual  for  bounded  stacks). 
Users  must  supply  an  equality  function  for  any  types  they 
define.  No  system  default  equality  (such  as  component-by¬ 
component  or  bit  identity)  can  capture  common  tricks  of 
implementation;  most  abstract  types  have  several  concrete 
representations  for  the  same  abstract  item.  If  the  result 
of  the  equality  test  is  false,  a  diagnostic  message  is 
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printed  indicating  that  the  axiom  has  failed  for  that 
particular  test  case. 

DAISTS'  structural  coverage  criteria 
DAISTS  requires  that  each  part  of  both  axioms  and 

implementing  code  be  executed.  Axioms  have  no  "statements," 
but  each  conditional  expression  can  be  treated  as  if  it  were 
a  conditional  statement.  DAISTS  also  monitors  an 

expression-analog  of  executing  each  statement  by  isolating 
each  subexpression  in  both  axioms  and  code.  It  monitors 
each  expression  evaluation  during  testing  and  reports  any 
expressions  that  were  not  evaluated  or  that  always  evaluated 
to  the  same  value.  As  in  conventional  programs  an 
unevaluated  expression  can  result  from  a  compiler 
optimization  of  parts  of  conditional  statements  {remember, 
DAISTS  is  working  with  production  compiled  code) .  An 
expression  that  does  not  vary  probably  represents  a  blunder 
in  selecting  test  data.  For  example,  in  the  expression: 

X* (X-l) * (X-5) * (Y+Z) 

a  collection  of  inputs  in  which  X  is  always  one  of  {o,  1,  5} 
will  fail  to  bring  out  the  programmer's  need  for  the  final 
factor.  A  constant  expression  within  an  axiom  can  reveal  a 
more  interesting  situation:  a  failure  of  the  implementation 
to  distinguish  abstract  objects. 

The  "debugging"  process  in  DAISTS  amounts  to  obtaining 
consistent  axioms  and  implementations  for  the  "obvious"  test 
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sets  and  augmenting  these  with  new  test  data  chosen  to 


satisfy  the  structural  criteria.  For  example,  the  first 
four  test  sets  for  Equall  were  chosen  to  satisfy  the  four 
subcases  distinguished  by  the  two  conditional  expressions  of 
the  axiom,  the  next  test  case  hit  the  only  uncovered 
statement  in  the  StackEqual  function  (the  return (False)  in 
the  while  loop) ,  and  the  last  two  cases  were  added  to  make 
expressions  vary. 

The  test  data  of  the  above  example  satisfies  DAISTS. 
The  implementation  returns  values  for  both  sides  of  each 
axiom  that  are  indistinguishable  (as  integers  for  EltType 
and  as  Stack  objects  according  to  StackEqual)  for  each  test 
set.  Each  path  through  the  axioms  and  the  statements  in  the 
implementing  code  are  exercised,  and  all  relevant 
subexpressions  in  both  acquire  at  least  two  different 
values.  (Not  all  subexpressions  are  meant  to  change  value; 
the  Result  subexpression  returned  by  NewStack  is  always  the 
same  value.) 

6 .  Implementation  details 

In  this  section,  we  describe  the  compilation  process  for  the 

portion  of  the  "bounded  stack"  example  shown  below. 

axioms 

Pop2 (BoundedStack  S,  int  I): 

Pop(Push(S,I) )  ■ 

if  Depth (S)  *  DepthLimit 
then  Pop ( S ) 
else  S; 


testooints 


BoundedStack  S1,S2  /*  "local"  variables  */ 

51  :=  Push (Push (Push (NewStack , 1) , 1) , 2) 

52  :*  SI 

while  Depth ( S 2 )  <  DepthLimit 
do 

Push (S2, Top (S2)+Top (Pop (S2) ) ) 
end 

testsets 

Pop2 :  (NewStack , 7)  ,  (SI, 22),  (S2,83), 

(Push (Pop (S2) ,19) ,82) ; 

start 

The  scanner  essentially  modifies  the  above  text 

(inserting  calls  to  the  run-time  library,  and  compiler 

directives  as  needed)  to  look  like: 

proc  Pop2 (BoundedStack  S,  int  I, 
int  Testsetnumber ) 

/+  monitoring  on  +/ 

if  StackEqual (Pop (Push (S, 1) )  , 

exor if  Depth (S)  =  DepthLimit 
exorthen  Pop ( S ) 
exprelse  S) 

then 

return  /*  axiom  held  true  */ 
end  if 

/+  monitoring  off  +/ 

call  Report_axiom_failur e ( "Pop2' , Testsetnumber ) 
proc  ma  testdriver 

BoundedStack  S1,S2 

/*  initialize  the  library  so  that  we  can  safely 
use  the  implementation  */ 
call  monitor ing_initialization 

51  :»  Push (Push (Put h (NewStack , 1) , 1) , 2) 

52  :=  SI 

while  Depth (S2)  <>  DepthLimit 
do 

S2  :=  Push (S2, Top (S2) +Top (Pop 'S2) ) ) 

end 
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/*  re-initialize  library  discarding  any  incidental 
monitoring  information  gathered  while  initializing 
SI  and  S2  */ 

call  monitor ing_initialization 

call  Pop2 (NewStack,7, 1)  /*  testset  1  (parm  3)  */ 

call  Pop2 {SI , 22, 2)  /*  testset  2  */ 

call  Pop2 (S2 , 83 , 3)  /*  testset  3  */ 

call  Pop2 (Push (Pop ( S 2 )  , 19) , 82 , 4)  /*  testset  4  */ 

/*  testing  is  finished,  report  test  results  */ 
call  monitor ing_report 

start  maintestdr iver 

The  /+  monitoring  ...  +/  directives  are  produced  so 
that  the  parser  doe^  not  invoke  the  monitoring  library  for 
code  that  is  generated  to  call  the  "axioms"  (in 
maintestdr iver)  or  code  generated  to  report  axiom  failures. 
The  "Pop2"  axiom  is  expanded  into  calls  on  implementation 
routines  that  compute  the  values  of  the  left  and  right  sides 
of  the  axiom,  and  "StackEqual"  compares  these  values.  If 
"StackEqual"  returns  false,  an  error  message  is  generated 
reporting  the  failure  of  the  axiom  to  hold  for  specific  test 
data.  The  testsets  section  has  been  translated  into  a 
series  of  calls  on  the  procedure  that  implements  the  "Pop2" 
axiom. 

The  parser  translates  this  "text"  into  quads,  adding 
quads  to  monitor  expression  evaluation  and  branch  execution. 
The  quads  that  are  produced  for  the  procedure  "Pop2"  are 
similar  to: 
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1  Segment  Pop2 

2  Call  StackEqual 

3  Call  Pop 


result*tl  type»boolean 
result»t2  type=stack 


/*  The  quads  for  the  sub-expression  "Push (S, I)". 

*  Note  that  the  parameters  are  listed  after  the  call  quad. 


*/ 


4 

Call  Push 

5 

expression_monitor 

S 

6 

parm  S 

7 

expression_monitor 

I 

8 

parm  I 

9 

endparms 

10 

parm  t3 

t3 

11 

expression_monitor 

12 

enaparms 

13 

parm  t2 

t2 

14 

expression_monitor 

quads  for  the  expression  i 

15 

Call  Depth 

16 

expression_monitor 

S 

17 

parm  S 

18 

endparms 

t5 

19 

express ion_monitor 

20 

call  DepthLimit 

21 

endparms 

22 

=  t5  t6 

23 

expression_monitor 

t7 

24 

exprif  t7 

Quads  for  the  "then  Pop(S) 

25 

call  Pop 

26 

expression_monitor 

S 

27 

parm  S 

28 

endparms 

t5 

29 

expression  monitor 

30 

exprthen  t? 

31 

express ion_moni tor 

S 

32 

exprelse  S 

result*t3  type*stack 
expr_number =1 

expr_number =2 


expr_number=3 


expr_number =4 

(right  side  of  axiom)  */ 

result=t5  type=integer 
expr_number=5 

expr_number=6 
result=t6  tvpe=integer 

result=t7  type=boolean 
expr_number=7 
result=t4  type=stack 

half  of  the  if  expression  */ 

result=t5  type=stack 
expr_number =8 


expr_number=9 
result=t4  type=stack 

expr_number =10 
result=t4  type=stack 


/*  the  if  expression  is  a  parameter  to  "StackEqual"  */ 

33  parm  t4 

34  endparms 

35  if  tl 
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36  then 

37  return 

38  endif 

39  call  report_axiom_failure 

40  parm  'Pop' 

41  parm  Testsetnumber 

42  endparms 

To  ensure  that  each  expression  takes  on  two  different 
values,  expression  evaluation  is  monitored  at  run  time. 
Each  monitored  expression  is  assigned  a  unique  expression 
number,  but  some  expressions  (tl,  t4,  and  t6)  are  not 
monitored.  StackEqual  (tl)  should  always  be  true  (or  the 
"Pop2"  axiom  will  fail  to  hold  for  a  test  case  and  an  error 
message  will  be  generated)  .  The  i_f  expression  ( 1 4 )  is  not 
monitored  because  its  value  is  either  the  value  of  its 
"then"  part  (t5  -  line  29)  or  its  "else"  part  (S  -  line  31) , 
both  of  which  must  have  varying  values  to  satisfy  expression 
monitoring.  The  call  to  DepthLimit  (t6,  line  20)  is  also 
not  monitored  because  the  function  has  no  parameters  and 
cannot  have  side  effects;  the  value  it  returns  cannot  vary 
and  is  treated  as  a  constant.  This  type  of  analysis  leads 
us  to  avoid  monitoring  expressions  like: 

Push (Push (NewStack , 24) ,4*20) 
because  "NewStack",  24,  4,  and  20  are  all  "constants”. 

For  each  monitored  expression,  the  code  generator 
produces  a  call  to  a  run-time  library  routine  whose 
arguments  are  the  address  of  the  expression  to  be  monitored, 
its  number,  its  size,  and  the  address  of  an  equality 
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function  whose  arguments  are  the  same  type  as  the 
expression. 


The  run-time  expression-monitoring  routine  saves  a  copy 
of  the  value  of  the  expression  being  monitored  (if  there  is 
room  in  a  storage  pool)  the  first  time  that  the  expression 
is  evaluated.  On  all  subsequent  evaluations,  the  routine 
compares  the  copy  against  the  (current)  value  of  the 
expression.  Once  an  expression  has  changed  value,  its 
initial  value  can  be  discarded.  A  global  flag, 
"notmonitor ing" ,  inhibits  monitoring  of  "equal_routine”  when 
it  is  invoked  by  "monitor_expression" .  The  structure  of  the 
run-time  expression  monitor  is  as  follows. 


rec  oroc  monitor_expression (number , address, 

size,equal_routine) 

if  notmonitor ing  0£  alreadyvar ied (number ) 
then 
return 
end 

if  alreadymonitored(number) 

then  /*  a  value  from  the  first  evaluation  is 

*  in  the  storage  pool.  See  if  it  changed  */ 
notmonitor ing  :=  true  /*  don't  monitor  equal_routine 

*  when  called  from  system 

*  routine  */ 

if  not  equal_routine (oldvalue (number ) ->value, 

addr ess- > value) 

then  /*  value  has  changed!  record  this  fact!  */ 
freespace (oldvalue (number ) )  /*  return  storage  */ 
alreadyvar ied (number )  :=  true 

end 

notmonitor ing  :=  false  /*  re-enable  monitoring  */ 
return 
end 

/*  haven't  saved  an  old  value  yet!  */ 
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if  not  space_available (s ize) 

then  /*  not  enough  storage  space  to  save  value  now!  */ 
seen_not_saved (number )  : =  true 
return 
end 

/*  there  is  room  to  save  the  value!  */ 
save_value (size , address ,old_value (number) ) 
already_monitored(number)  :a  true 

end  /*  monitor_express ion  */ 

Since  the  (JNIVAC  implementation  did  not  have  a  large 

address  space,  the  storage  pool  for  saving  values  was  a 

statically  allocated  buffer  of  about  five  thousand  words, 

which  generally  was  sufficient  for  testing  modules  up  to 

approximately  400  lines  in  length  (200  lines  of  abstract 

type  implementation,  150  lines  of  specification,  and  50 

lines  of  test  data) .  On  occasion  the  storage  pool 

overflowed  and  some  of  the  expression  values  could  not  be 

saved  on  their  first  evaluations.  In  these  cases,  DAISTS 

reports  the  list  of  expressions  for  which  data  had  been 

lost.  The  programmer  may  then  run  the  testing  session  again 

(either  with  a  larger  static  storage  pool  or  with  extra  test 

data  so  that  some  of  the  expressions  whose  values  did  not 

vary  on  the  first  testing  session  would  vary,  freeing  up 

some  of  the  storage  pool) .  The  VAX  implementation  is  able 

to  make  use  of  the  VAX's  large  address  space  for  storage 

allocation  to  save  the  expression  values  dynamically. 

A  problem  with  any  system  that  monitors  program 
execution  is  that  of  reporting  the  results  to  the 
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programmer.  It  is  easy  to  map  statement  numbers  to  source 
text  line  numbers.  However,  there  is  no  simple  way  to  map 
expression  numbers  onto  text  lines.  DAISTS  provides  a 
listing  of  expression  numbers  with  the  text  of  the 
expressions  they  represent  by  traversing  the  quads  at 
compile  time  (via  an  inorder  traversal,  treating  identifiers 
as  "leaves"  in  the  tree  of  quads) ,  and  inserting  parenthesis 
as  required  by  operator  precedences.  The  output  for  our 
example  looks  similar  to: 


Expr  number  Text  Line 


1  3 

2  3 

3  3 

4  3 

5  4 

6  4 

7  4 

8  5 

9  5 

10  6 


Expression 

S 

I 

Push (S , I) 

Pop (Push (S, I) ) 

S 

Depth (S) 

Depth (S)  *  DepthLimit 
S 

Pop(S) 

S 


Sample  monitoring  messages  appear  below. 

Expression  number  7  always  evaluated  to  the  same  value. 
Expression  numbers  8,  9  were  never  evaluated. 
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4.  Exoer iment 


We  performed  an  exploratory  study  that  compared  program 
development  with  DAISTS  against  a  more  conventional 
programming  technique.  The  goals  of  the  study  were  to  show 
(1)  that  the  use  of  DAISTS  would  reduce  the  number  of 
delivered  errors,  (2)  that  using  DAISTS  would  not  prolong 
the  program  testing  process,  aids  often  produce  insufficient 
tests. 

In  evaluating  DAISTS  there  are  really  two  primary 
issues  to  be  resolved:  1)  the  ease  with  which  users  write 
axioms,  and  2)  the  ability  of  users  to  develop  programs 
consistent  with  axioms.  We  concentrated  on  the  second 
issue,  program  development,  rather  than  specification 
development.  Obviously,  if  the  program  development  task 
proved  too  difficult,  the  system's  worth  would  be  questioned 
because  writing  formal  specifications  before  development 
would  only  make  the  process  more  difficult. 

.i*i*  Methodology 

An  intermediate  class  in  programming  languages  was  divided 
into  two  groups,  given  identical  English  language 
descriptions  of  the  abstract  type  "bounded-list-of- 
integers",  and  assigned  to  produce  implementations  of  twelve 
operations  for  the  type  in  SIMPL-D.  The  axiom  group  used 
algebraic  specifications  to  test  their  implementations, 
while  the  control  group  used  the  more  traditional  test 


driver  method.  The  axiom  group  was  given  the  axioms  for  the 
type,  and  the  control  group  was  given  a  test  driver  that 
used  most  of  the  abstract  operations  to  sort  groups  of 
integers.  Subjects  were  allowed  to  produce  other  axioms  or 
test  drivers  at  their  discretion.  Since  some  control  group 
subjects  would  undoubtedly  test  with  only  the  sort  routine 
while  others  would  write  their  own  test  drivers  (at  least 
for  the  three  functions  not  used  by  the  sort  routine) ,  we 
would  get  some  information  about  their  ability  to  judge  test 
coverage.  Both  groups  had  to  develop  their  own  test  data. 
At  the  end  of  the  experiment,  we  examined  the  programs  to 
discover  the  residual  errors. 

4.1.1.  Choosing  the  groups 

The  class  (of  79  students)  met  together  for  lecture  twice  a 
week,  and  was  divided  into  four  smaller  groups  that  met  once 
a  week  with  one  of  two  teaching  assistants.  Two  of  the 
small  groups  (one  from  each  assistant)  were  combined  to  form 
the  axiom  group  (45  students) ,  and  the  other  two  groups 
formed  the  control  group  (34  students) .  Five  control  group 
subjects  and  four  axiom  group  subjects  did  not  turn  in  any 
project,  and  were  dropped  from  the  study.  Despite  warning 
the  subjects  several  times  that  every  compilation  was  being 
recorded  and  that  they  were  required  to  work  independently, 
three  pairs  of  projects  were  so  (remarkably)  similar  that  we 
could  not  objectively  consider  them  to  be  independent 
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efforts.  One  of  each  pair  of  the  "non-independent"  projects 
(the  "dependent"  one  if  determinable)  has  been  omitted. 
This  left  40  subjects  in  the  axiom  group,  and  27  subjects  in 
the  control  group. 

To  check  that  the  two  groups  were  of  approximately  the 
same  ability,  we  analyzed  the  grades  that  they  received  for 
the  semester.  This  analysis  showed  only  one  statistically 
significant  difference  between  the  two  groups  —  the  control 
group  had  slightly  higher  examination  scores.  (See  Table  1 
below. ) 


Table  1  Group  Differences. 


Axiom  Group  j 

j  Control  Group 

Letter  grade 

Mean 

2.44 

2.54 

(A  *  4.0) 

St  dev 

.90 

.94 

Level 

<  80% 

Project  grade 

Mean 

120.8 

114.1 

(Max  =  150) 

St  dev 

17.8 

26.8 

Level 

<  44% 

Exam  Grade 

Mean 

41.00 

45.81 

(Max  =  100) 

St  dev 

12.12 

8.90 

Level 

<  7% 

Letter  grades  on  a  scale  1*D,  2=C,  etc. 

Project  grades  (five  projects  not  counting  experiment) 
on  a  150  point  scale. 

Composite  exam  grades  on  a  100  point  scale. 

Significance  levels  for  a  two-tailed  Mann-Whitney 
U-test  [Siegel  1956] . 
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£.1.2*  The  Project 

We  chose  to  assign  a  small  project  (approximately  150  lines) 
to  implement  "bounded  list-of-integers. "  The  operations  were 
described  in  English  in  the  project  handout  (see  Appendix 
I) ,  which  also  contained  instructions  for  using  the 
appropriate  processor.  The  subjects  were  told  that  they 
were  to  implement  all  of  the  functions  described  in  the 
handout  and  present  results  demonstrating  that  the  sort 
routine  or  axioms  executed  with  no  obvious  errors. 

A  manual  describing  uhe  implementation  language  and 
giving  other  specific  information  (how  the  axiom  group 
accessed  the  axioms  and  how  the  control  group  could  obtain 
the  standard  driver  or  write  their  own  drivers)  was  also 
distributed.  The  axioms  and  the  test  driver  program  that 
were  provided  are  in  Appendices  II  and  III  respectively. 

Since  the  test  data  had  to  be  submitted  along  with  the 
program  at  compile  time  for  the  axiom  group  (to  allow  DAISTS 
to  construct  its  test  driver) ,  the  control  group  was  also 
required  to  submit  their  test  data  with  their  compilation 
requests  to  make  the  development  environments  more  nearly 
equivalent. 

We  also  provided  separate  lecture  and  laboratory 
meetings  for  the  two  groups,  and  tried  to  exchange 
experimenters  so  that  each  group  met  with  each  experimenter 
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to  nullify  any  bias  in  our  lectures.  The  subjects  were 
informed  that  they  had  been  divided  into  two  groups,  and 
were  asked  not  to  exchange  information  about  how  the  two 
groups  were  different.  However,  some  of  the  details  of  the 
SXMPL-D  language  were  discussed  with  both  groups  present. 

4^.1. 2*  Data  Collection 

A  special  processor  was  set  up  to  limit  access  to  DAISTS;  it 
prohibited  members  of  the  axiom  group  from  writing  separate 
test  drivers  and  members  of  the  control  group  from  using  the 
axioms.  This  processor  also  saved  a  copy  of  a  every  deck 
submitted  to  allow  us  to  examine  program  development 
histories.  This  approach  led  to  several  identical  decks 
being  saved  by  the  submission  processor  —  either  a  subject 
would  run  a  deck  at  his  terminal  and  then  run  the  deck  again 
to  generate  a  listing  on  the  printer,  or  programs  failed  to 
complete  execution  before  their  system-default  time  limit 
was  exhausted  so  the  decks  were  resubmitted  with  larger  time 
limits . 

4.1.4.  Identifying  errors 

After  the  subjects'  projects  were  collected  and  graded,  the 
files  of  decks  saved  by  the  submission  processor  were 
examined.  For  each  subject,  the  deck  that  corresponded  to 
the  listing  that  was  submitted  by  the  subject  for  grading 
was  separated  into  the  class  definition  and  the  debugging 
data.  We  then  debugged  each  implementation,  both  by  "desk 
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checking"  and  by  using  the  DAISTS  system.  Many  of  the 
errors  that  we  found  were  detected  simply  by  turning  on  the 
subscript-checking  feature  of  the  compiler  (apparently  few 
of  the  subjects  used  this  feature)  . 

As  we  were  debugging  implementations,  we  found  that 
several  implementations  had  "subjective  restrictions"  that 
were  not  addressed  in  the  project  assignment.  These 
restrictions  could  also  be  interpreted  as  errors,  but  a  case 
could  be  made  for  allowing  them.  For  example,  one  subject 
stored  only  single-digit  positive  integers.  Also,  several 
subjects  could  correctly  store  any  integers  except  zero, 
which  they  used  as  markers  in  their  representations. 

When  these  "subjective  errors"  were  included,  the 
results  were  not  substantially  different  from  the  results 
reported  below,  which  come  from  only  counting  the  "objective 
errors"  —  code  that  fails  no  matter  how  favorable  the  input 
values  selected. 

Measuring  errors 

We  also  faced  a  dilemma  in  choosing  how  to  report  errors. 
We  feel  that  the  most  conservative  objective  measure  that  we 
can  use  is  functions  containing  errors .  If  a  function  in 
the  submitted  project  had  to  be  changed,  regardless  of  the 
number  of  changes  that  had  to  be  made  to  correct  the 
function,  it  was  counted  as  a  single  "function  containing  an 
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error."  We  like  the  resolution  of  this  measure  because  1)  it 
is  more  nearly  representation-independent  than  any  other 
error  measure;  and  2)  the  project  description  defined 
functions,  the  axioms  specified  functions,  and  the  sort 
routine  used  the  specified  functions. 

We  compared  our  measure  to  distinct  errors  and  error 
occurrences  [Gannon  77] ;  where,  if  the  same  error  in 
computing  the  length  of  a  list  was  made  in  three  places,  it 
would  count  as  one  distinct  error,  but  three  error 
occurrences.  Our  data  produced  similar  results  for  both  of 
these  measures  and  for  the  measure  "functions  containing 
errors . " 

Several  of  the  subjects  made  errors  in  selecting  their 
representations.  One  subject  used  a  circular  list  and  had 
an  ambiguity  in  his  representation  between  a  full  list  and 
an  empty  one.  This  error  could  only  be  fixed  by  adding  a 
word  to  his  representation  and  repairing  many  of  the 
functions.  Another  subject's  project  was  corrected  by 
merely  changing  the  size  of  an  array  in  his  representation 
(no  functions  needed  changing) .  These  subjects  were  charged 
with  one  incorrect  function  to  account  for  the  change  to  the 
representation  (in  addition  to  any  incorrect  functions  for 
which  they  were  charged) . 
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In  the  results  reported  below,  the  measure  functions 
that  contained  objective  errors  was  used. 

£.1.. Measur ing  Cost  of  Development 

It  is  inherently  difficult  to  measure  programmer  effort.  It 

is  especially  difficult  to  measure  the  effort  of  students 

who  do  not  work  regular  schedules  and  who  are  not  inclined 

to  keep  track  of  effort  on  a  project  near  the  end  of  a 

semester.  We  used  number  of  distinct  runs  as  the  measure  of 

development  cost  since  it  was  the  only  enforceable  metric  ! 

that  we  could  employ. 

Results 

Our  hypotheses  that  the  axiom  group  would  deliver  fewer 
errors  than  the  control  group  is  tested  by  comparing  both 
the  number  of  functions  that  contained  errors  1)  counting 

»  j 

the  functions  that  were  assigned,  and  2)  counting  only  the 
functions  contained  in  the  sort  routine  given  to  the  members 

of  the  control  group.  Our  hypotheses  that  DAISTS  usage  I 

would  not  increase  the  program  development  cost  is  tested  by 
comparing  the  number  of  distinct  runs  used  by  the  members  of  ■ 

each  group.  The  hypotheses  that  the  control  group  members  .  >* 

could  not  judge  the  effectiveness  of  their  test  coverage  is  : 

[' 

tested  two  ways:  1)  by  looking  for  a  difference  between  the  j 

control  group's  performances  on  just  the  functions  tested  by  ! 

the  sort  routine  and  their  performances  on  all  the 
functions,  and  2)  by  considering  the  performance  of  the 
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sub-groups  of  the  control  group  that  (a)  did,  and  (b)  did 
not  write  their  own  test  driving  routines. 

Since  the  sort  program  tested  9  of  the  12  list 
operations,  we  have  reported  both  the  number  of  incorrect 
functions  tested  by  the  sort  routine  and  the  total  number  of 
incorrect  functions.  The  subjects  were  required  to 
implement  all  the  functions  and  were  encouraged  to  write 
extra  functions  to  display  list  objects  as  a  debugging  aid. 

In  the  tables  below,  we  report  the  means  and  standard 
deviations  of  the  number  of  incorrect  functions  tested  by 
both  the  axioms  and  the  sort  routine,  the  total  number  of 
incorrect  functions,  and  the  number  of  distinct  runs.  The 
significance  levels  shown  were  generated  by  one-tailed, 
Mann-Whitney  U-tests  [Siegel  56]. 

£.2.1.  Original  Groups 

The  two  groups  had  similar  numbers  of  incorrect  functions 
when  we  consider  only  those  functions  tested  by  the  sort 
routine,  and  the  number  of  distinct  runs  were  also  similar. 
While  the  means  favored  the  members  of  the  axiom  group  (an 
average  of  .18  fewer  incorrect  functions  out  of  the  9 
functions  tested  by  the  sort  routine  and  .71  fewer  distinct 
runs) ,  the  differences  were  not  significant.  As  expected, 
the  axiom  group  did  significantly  better  than  the  control 
group  in  eliminating  errors  in  all  the  functions  assigned. 
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Table  2  All  Axiom  (40)  and  Control  (27)  Subjects 


Axiom  group  Sort  group  Level 


Incorrect  sort  functions  .60(1.18) 
All  incorrect  functions  .82(1.51) 
Distinct  runs  11.77(5.65) 


.78(1.64) 

1.78(2.20) 

12.48(8.53) 


NS 

<.003% 

NS 


4. 2.2.  Successful  Subjects 

We  found  that  some  of  the  subjects  turned  in  projects  that 
were  not  "successfully  completed"  —  subjects  in  the  axiom 
group  had  messages  about  inconsistent  axioms  and 
implementations,  and  subjects  in  the  control  group  turned  in 
projects  for  which  the  sort  routine  would  not  correctly  sort 
their  test  data.  By  successfully  completing  the  project,  we 
mean  only  that  the  output  of  the  program  that  was  submitted 
for  grading  displayed  no  obvious  errors.  In  the  axiom 
group,  32  of  40  subjects  successfully  completed  the  project, 
and  22  of  27  control  group  subjects  were  successful. 

Considering  only  those  subjects  who  successfully 
completed  the  project,  the  axiom  group  did  marginally  better 
than  the  control  group  even  on  the  functions  tested  by  the 
sort  routine.  This  result  appears  despite  the  sort  routine 
doing  a  good  job  of  exposing  the  errors  in  these  routines 
for  those  subjects  choosing  good  sets  of  data  to  use  with 
it.  (When  the  data  for  the  sort  program  contained  all  the 
boundary  cases  of  the  sort  routine,  all  the  boundary  cases 
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of  the  list  fur.ctions  were  tested).  Of  coarse,  the  results 
are  even  more  scriking  when  we  consider  all  the  functions. 
The  axiom  group  delivered  more  co^ect  functions  than  did 
the  control  group  without  taking  more  runs. 


Table  3  Successful  Axiom  (32)  and  Control  (22)  Subjects 


Axiom  group  Sort  group  Level 


Incorrect  sort  functions  .12(  .33) 
All  incorrect  functions  . 19 (  .39) 
Distinct  runs  10.97(5.60) 


. 23 (  .42)  <20% 

1.23(1.20)  <.004% 

11.41(7.60)  NS 


We  have  subdivided  the  successful  control  group  into 
two  groups  for  further  comparison:  those  that  wrote  and  ran 
small  test  driver  programs  in  addition  to  running  the  sort 
program  (which  is  more  like  an  integration  test  than  a  unit 
test) ,  and  those  that  used  the  sort  routine  exclusively  for 
testing.  Of  the  22  successful  control  group  members,  7 
wrote  their  own  driver  programs. 

4.2 .3.  Subjects  Writing  Their  Own  Dr iver s 

We  expected  that  those  subjects  in  the  control  group  who 
wrote  driver  programs  would  test  as  effectively  as  the  axiom 
group,  but  would  require  more  runs  to  debug  their  own 
drivers.  The  data  in  Table  4  supports  these  hypotheses  for 
the  sort  functions  only.  Even  driver-writing  subjects  did 
not  produce  as  many  correct  functions  as  the  axiom  group 
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did . 


Table  4  Successful  Axiom  (32)  and 

Driver-Writing  (7)  Subjects 


Axiom  group  Driver  group  Level 


Incorrect  sort  functions  . 12  (  .33) 
All  incorrect  functions  . 19 (  .39) 
Distinct  runs  10.97(5.60) 


. 14 (  .35)  NS 
. 57 (  .49)  <2% 

15.14(5.82)  <4% 


Examining  the  runs  of  the  driver-writing  subjects  to 
determine  why  their  efforts  did  not  match  those  of  the  axiom 
group,  we  find  a  distinct  lack  of  testing  discipline.  Five 
of  the  7  subjects  had  test  drivers  that  could  exercise  all 
the  functions.  Four  of  the  subjects  used  effective  tests, 
trying  a  variety  of  objects  in  different  operations,  while 
two  other  subjects  with  extensive  test  drivers  just  did  not 
seem  to  use  enough  data  to  cover  the  necessary  cases.  Four 
of  the  subjects  used  drivers  before  using  the  sort  routine 
seriously  as  an  integration  test.  Two  other  subjects  used 
drivers  only  in  response  to  specific  errors  that  occurred  in 
testing  with  the  sort  routine. 

4.2.4.  Subjects  Testing  with  the  Sort  Program  Only 
Those  subjects  testing  only  with  the  sort  program  used  an 
average  of  1.3  fewer  runs  than  di^  the  members  of  the  axiom 
group.  However,  they  did  not  produce  as  many  working 
functions,  even  when  we  consider  only  the  functions  tested 
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by  the  sort  program  (8.73  to  8.88).  Part  of  the  explanation 
for  this  result  may  be  that  the  sort  program  did  not 
encourage  the  members  of  the  control  group  to  test  more 
thoroughly.  The  sort  program's  effectiveness  as  a  testing 
vehicle  was  impaired  by  poor  selections  of  test  data  that 
did  not  include  the  boundary  cases  of  the  sort's  domain. 

Table  5  Successful  Axiom  (32)  and 

Sort-Only  (15)  Subjects 

Axiom  group  Sort  group  Level 

Incorrect  sort  functions  .12(  .33)  .27(  .44)  <14% 

All  incorrect  functions  . 19 (  .39)  1.53(1.31)  <.002% 

Distinct  runs  10.97(5.60)  9.67(7.70)  <8% 

4.3.  Conclusions  from  the  Experiment 

While  the  axiom  group  needed  slightly  more  runs  to  satisfy 
DAI STS ,  its  members  correctly  developed  more  functions.  The 
discipline  of  testing  with  DAISTS  helped  even  inexperienced 
users  avoid  less  systematic  testing  methods.  Even  if  we 
consider  only  the  subjects  in  our  study  who  wrote  their  own 
test  drivers,  we  observe  a  variety  of  questionable  testing 
practices  -  omitted  functions,  failures  to  consider  boundary 
cases,  and  generally  insufficient  test  data.  The  formal 
specification  required  by  DAISTS  identifies  the  boundary 
cases  and  clearly  defines  their  treatment.  Furthermore, 
DAISTS  run-time  monitoring  routines  ensure  that  the  code 


handling  boundary  cases  is  exercised. 


Performing  this  study  gave  us  insights  that  could  help 
us  improve  our  system.  Several  residual  errors  might  have 
been  exposed  by  special-values  testing  strategies 
[Howden  78],  e.g.,  adding  tests  that  include  the  zeros  of 
the  types  (0  for  integers,  null  and  blank  strings,  NewList, 
etc.)  and  the  constants  that  appear  in  the  text  of  the 
implementation  ( 'AddFirst  (NewList,  22)  ' ,  '76',  '"constant 
strings"',  etc. ) . 
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5. 


Use  of  DAISTS  in  an  Implementation 
While  the  experiment  reported  above  attempts  to  show  that 
DAISTS  can  be  used  to  reduce  errors  in  the  program 
development  process,  it  does  not  address  the  problem  of 
using  specifications  and  tools  on  larger  software  projects. 
Only  a  few  reports  of  their  use  for  other  than  small 
examples  have  appeared  in  the  literature:  [Gerhart  and  Wile 
79]  specified  and  verified  part  of  a  multiple  user  file 
updating  module  using  algebraic  axioms  with  the  AFFIRM 
system;  [Guttag  and  Horning  80]  specified  a  display 
interface.  This  chapter  relates  our  experience  using  DAISTS 
to  specify  and  implement  a  record-oriented  text  editor 
similar  to  one  described  in  [Kernighan  and  Plauger  81] . 


_5.1.  Design  Overview 

The  text  editor  was  implemented  in  five  modules  including 
data  type  definitions  for  records ,  files ,  and  patterns ,  and 
modules  to  implement  a  record-oriented  editor  and  a  simple 
user  interface.  The  module-interface  structure  of  the 


system  is  shown  below: 

User 

Interface 


V 


v 

Editor 


/ 


/ 


Patterns 


\ 

\ 

\  \ 

— -  \ 

\  ! 

V  V 

Files 


\ 


/ 


■>  Records  <- 


The  editor  implementation  takes  two  files  and  interprets  one 
file  as  a  list  of  editing  commands  to  be  applied  to  the 
other  "text"  file.  Currently,  the  user  Interface  contains 
only  a  small  loop  that  reads  a  record  from  the  terminal, 
converts  it  to  a  file  (containing  a  single  record) ,  submits 
it  to  the  editor  with  the  text  file  (built  by  previous 
commands) ,  and  saves  the  result  in  the  text  file.  This 
trivial  user  interface  could  easily  be  replaced  with  a  more 
powerful  one  that  would  include  "meta-commands"  for 
accessing  permanent  disk  files  and  reading  command  streams. 

5,. 1.1.  Basic  Editor  Commands 

The  editor  module  updates  its  text  file  and  maintains  a 
pointer  to  the  current  record  in  the  file.  Editor  commands 
are  line-oriented  and  operate  relative  to  the  current 
position  in  the  file.  Each  command  may  have  an  optional 
address  (or  address  range)  that  indicates  the  file  position 
(or  range  of  file  positions)  where  it  is  applied.  The  basic 
editor  commands  are  shown  below. 

i<text>  Inserts  the  <text>  into  the  file  after 

the  current  record,  leaving  the  editor 
positioned  at  the  inserted  record.  If 
the  file  is  positioned  before  its  first 
record,  the  inserted  record  becomes  its 
new  first  record. 

d  Deletes  the  current  record,  positioning 

the  editor  to  the  previous  record.  If 
there  is  no  previous  record,  the  editor 
is  positioned  before  the  first  record. 
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p  (or  <Nullrecord>) 


Prints  the  current  record,  without 
changing  the  position  in  the  file. 


s<D><pattern><D><text><D>  Substitutes  <text>  for  the  first 

occurrence  of  the  <pattern>  in  the 
current  record.  The  delimiter  <D>  may 
be  any  character  not  appearing  in  the 
<pattern>  or  the  <text>.  The  position 
of  the  editor  is  not  changed.  If  the 
<pattern>  is  not  present  in  the  current 
record,  no  change  is  made. 


5.1.2.  Command  Addresses 


Prefixing  a  command  with  an  address  positions  the  editor  at 
the  record  selected  by  the  address  and  then  executes  the 
command.  Prefixing  a  command  with  an  address  range 
(indicated  by  two  addresses  separated  by  a  comma)  causes  the 
command  to  be  executed  at  each  of  the  records  indicated  by 
the  range  and  positions  the  editor  at  the  record  selected  by 
the  second  address.  If  the  second  address  of  a  range 
identifies  a  file  position  that  is  before  that  identified  by 
the  first  address,  it  is  ignored.  After  the  last  execution 
of  an  insert,  delete,  or  substitute  command,  the  editor 
prints  the  (then  current)  record. 


Addresses  in  the  editor  may  be  indicated  in  any  of  the 
following  ways: 


<number>  The  <number>'th  record  in  the  text  file.  If 
<number>  is  zero  or  negative,  the  position  is  BEFORE 
the  first  record  of  the  file.  If  <number>  is 
greater  than  the  length  of  the  file,  the  position  is 
that  of  the  LAST  record  of  the  file. 
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.  The  current  position  of  the  editor  (at  the  time  that 

the  command  is  interpreted) . 

$  The  last  record  of  the  file. 

/<pattern>/  The  file  is  searched,  starting  at  the  record  after 
the  current  one,  toward  the  end  of  the  file,  until  a 
record  containing  the  <pattern>  is  found.  The 
position  of  the  record  containing  the  <pattern>  is 
the  address  used.  If  the  <pattern>  is  not  present 
in  the  file  after  the  current  record,  the  address  of 
the  last  record  in  the  file  is  used. 

\<pattern>\  The  file  is  searched,  starting  at  the  record  before 
the  current  one,  toward  the  beginning  of  the  file, 
until  a  record  containing  the  <pattern>  is  found. 
The  position  of  the  record  containing  the  <pattern> 
is  the  address  used.  If  the  <pattern>  is  not 
present  in  the  file  before  the  current  record,  the 
address  zero  (before  the  first  record  of  the  file) 
is  used. 


j>.l  .3.  Patterns 

Patterns  are  used  to  identify  file  positions  and  to  select 
parts  of  records  for  replacement  in  the  substitute  command. 
The  patterns  that  we  implemented  are  similar  to  those  of 
[Kernighan  and  Plauger  81] : 


c  literal  character 

?  any  character 

beginning  of  record 
$  end  of  record 

[...]  character  class  (match  any  of  these  characters) 

(*...]  negated  character  class  (all  but  these  characters) 

*  closure  (zero  or  more  occurrences  of  previous  pattern) 

§c  escaped  character  (e.g.  9  [ ,  9%  ...) 

Character  classes  contain  one  or  more  of  the  following  elements: 
c  literal  character,  including  [ 

a-c  range  of  characters  (digits,  lower  or  upper  case) 

9c  escaped  character  (@Ar  9],  99,  ...) 
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Patterns  match  the  leftmost  sequence  of  characters  in  a 


record,  matching  as  many  characters  as  possible.  For 
example,  the  pattern  "a*bc*"  matched  with  the  record 
"xbzaaabccccc"  matches  one  character  in  the  second  character 
position  of  the  record,  and  matched  with  the  record 
"xyzaaabccccc"  matches  nine  characters  starting  at  the 
fourth  character  position. 


^.jL.4^.  Sample  Editing  Commands 

Some  sample  editing  commands  are  shown  below. 


l,.d  deletes  all  of  the  records  from  the  beginning 

of  the  file  up  to  (and  including)  the  current 
record.  The  editor  will  be  positioned  before 
the  (then)  first  record  of  the  file. 

.,$p  prints  all  of  the  records  from  the  current 

one  to  the  end  of  the  file,  leaving  the 
editor  positioned  at  the  last  record  of  the 
f  ile . 


\begin\,/end/s/x/y/  changes  the  first  occurrence  of  x  to  y  on 

each  of  the  records  from  the  most  recent 
"begin"  to  the  next  "end".  The  editor  is 
positioned  at  the  record  containing  "end"  (or 
at  the  last  record  of  the  file  if  "end"  is 
not  present) . 

/ [A-Z] [A-Za-zO-9] */  prints  the  next  record  of  the  file  containing 

an  identifier  starting  with  a  capital  letter, 
leaving  the  editor  positioned  there.  If  no 
record  contains  such  an  identifier,  the  last 
line  of  the  file  is  printed. 


5.2.  Specifying  the  Types 

Formal  specifications  were  written  for  four  modules: 
records,  files,  patterns,  and  editor.  We  did  not  specify 


the  user 


interface  because  communicating 


with  the 


I 

environment  is  accomplished  via  side  effects. 


5^.  2.1.  Records 

The  type  record  presents  no  specification  problems  because 
it  behaves  much  like  the  (familiar)  type  "character  string" 
found  in  programming  languages  like  PL/I.  Functions 
generate  null  records,  measure  record  lengths,  convert  a 
character  into  a  record  of  length  one,  extract  the  first 
character  from  a  record,  delete  the  first  character  of  a 
record,  concatenate  two  records,  extract  a  subrecord  of  a 
record,  locate  a  (shorter)  record  in  a  (longer)  one,  and 
judge  the  equality  of  records.  To  support  files  and 
patterns,  we  later  added  functions  to  locate  an  unescaped 
character  in  a  record,  convert  a  record  to  an  integer,  and 
to  maintain  a  sorted  set  of  characters  in  a  record. 

5.2.2.  Files 

Our  type  files  is  more  like  that  of  [Cleaveland  80]  than  the 
files  of  Pascal.  Records  are  inserted  into,  or  deleted 
from,  a  file  at  the  position  of  the  file's  read/write  head. 
Inserting  a  record  causes  the  head  to  be  positioned  at  the 
new  record,  while  deleting  a  record  causes  the  head  to  be 
positioned  at  the  preceding  record.  Other  operations  move 
the  head  forward  and  backward  in  the  file,  test  if  the  file 
is  positioned  before  the  first  record  or  at  the  last  record, 
return  the  address  or  value  of  the  current  record  (i.e.,  the 
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one  under  the  head) ,  and  replace  the  current  record. 

One  of  the  most  interesting  axioms  for  files  defines 

the  composition  of  Advance  and  Insert. 

Advance (Insert (R,X) )  * 
if  Atend(X) 

then  Insert(R,X) 

else  Insert (CurrentRec (Advance (X) )  , 

Replace (R, Advance (X) )) ;  Part  of  the 

reason  that  this  axiom  was  difficult  to  write  is  that  the 

Advance  operation  modifies  only  the  positioning  of  the  file, 

while  the  Insert  operation  modifies  the  contents  and  the 

positioning  of  the  file. 

If  the  file  is  already  positioned  at  the  last  record, 
Advance  has  no  effect.  Otherwise,  the  value  of  the  record 
that  should  wind  up  under  the  read/write  head  is  extracted 
(by  "CurrentRec (Advance (X) )")  ,  the  file  is  advanced,  the 
record  that  was  to  have  been  inserted  replaces  the  extracted 
value  (via  "Replace (R, Advance (X) )") ,  and  the  extracted  value 
is  reinserted,  making  it  the  (now)  current  record  in  the 
f  ile . 


In  [Cleaveland  80]  the  axiom  specifying  the  result  of 
advancing  past  an  inserted  record  was: 

Advance (M(X, Insert (R,Y) ) )  *  M (Insert (R,X) ,Y) 
where  M  maps  two  files  (the  first  containing  all  records  up 
to  and  including  the  current  record  and  the  second 
containing  the  remaining  records  in  reverse  order)  into  a 
single  file.  This  has  the  effect  of  using  the  second  file 


57 


as  a  stack  of  records,  and  an  obvious  implementation  would 
be  to  implement  a  file  as  two  stacks  of  records.  Although 
nobody  would  implement  a  file  this  way,  these  specifications 
have  more  representational  bias  than  ours. 

Taking  the  file  apart  and  reconstructing  it  in  the 
axioms  allowed  us  to  avoid  a  hidden  function  to  keep  track 
of  the  position  of  the  read/write  head.  We  were  able  to  use 
CurrentRec  to  "hold"  the  value  of  a  record,  perform  the 
appropriate  manipulation,  and  then  re-insert  the  "held" 
value.  For  example,  in  the  specification  of 
Delete (Back (X) ) ,  two  records  are  deleted  and  the  value  of 

the  first  deleted  record  is  re-inserted. 

Delete (Back (X) )  * 

if  Attop (Back (X) ) 
then  Back (X) 

else  Back (Insert (CurrentRec (X) , Delete (Delete (X) ))) ; 
5.2.2*  Patterns 

Our  implementation  of  the  pattern  matcher  closely  follows 
that  in  [Kernighan  and  Plauger  81]  except  that  we  did  not 
allow  patterns  to  match  across  record  boundaries. 

Our  specification  for  patterns  employs  a  technique  used 
by  [Gerhart  and  Wile  79]  in  the  Delta  experiment.  They 
built  sequences  of  instructions  describing  the  net  effects 
of  operations  on  tree-like  files  by  interpreting  the  words 
representing  the  "constructor  histories"  of  files,  and  then 
applied  the  instructions  to  a  fresh  copy  of  the  file  to 
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obtain  its  new  value.  Two  of  our  functions,  PatfromRec  and 
MatchPat,  performed  similar  tasks.  PatfromRec  interpreted 
records  contairing  patterns  into  sequences  of  pattern- 
construction  operations  producing  an  object  of  type  pattern. 
Then  MatchPat  used  the  pattern  objects  to  determine  the 
position  within  a  record  where  the  pattern  matched. 


The  PatfromRec  specification  is  shown  below. 

PatfromRec (R)  = 

if  RecordEqual (R,NullRec) 
then  NullPat 

else  if  CharofRec (R)  =  "0" 

then  /*  escaped  character  */ 
if  RecLength(R)  =  1 

then  ErrorPat  /*  no  character  present  */ 
else  ConcatPat (Lit (CharofRec (Rest (R)  ) ) , 

PatfromRec (SubRec (R, 3 ,MaxLen)  ) ) 
else  if  CharofRec (R)  =  ”?" 
then  /*  Arb  */ 

ConcatPat (Arb, PatfromRec (Rest (R) ) ) 
else  if  CharofRec (R)  = 

then  /*  Closure  */ 

ConcatPat (Closure, PatfromRec (Rest (R) ) ) 
else  if  CharofRec (R)  = 

then  /*  Beginning  of  Line  */ 

ConcatPat (Bol , PatfromRec (Rest (R) ) ) 
else  if  CharofRec (R)  = 

then  /*  End  of  Line  */ 

ConcatPat (Eol , PatfromRec (Rest (R) ) ) 
else  if  CharofRec(R)  * 

then  /*  Choice  */ 

ConcatPat 

(Choice ( SubRec (R, 1 , EscapedFind (R, " ] " » "0" ) ) } , 
PatfromRec (SubRec (R, EscapedFind (R, " ] " , " 0" ) +1 , 

MaxLen) ) ) 

else  /*  literal  character  */ 

ConcatPat (Lit (CharofRec (R) ) , PatFromRec (Rest (R) ) ) ; 

For  example,  a  record  containing  the  characters: 

~X*$ 

to  match  a  line  consisting  of  zero  or  more  X's  is 


interpreted  by  PatfromRec  into  the  sequence  of  pattern 
operations : 

ConcatPat (3ol,  /*  beginning  of  line  */ 

ConcatPat (Lit ( 'X' ) ,  /*  literal  "X"  V 
ConcatPat (Closure ,  /*  */ 

/*  and  end  of  line  "$"  */ 
ConcatPat (Eol,NullPat) ) ) ) 

Either  a  single  pattern  within  a  record  (e.g.,  missing 
characters  as  in  ' [ a-z "  and  ambiguous  range 

specifications  like  "[f-3]"  and  ''[m-d]''),  or  the  combination 
of  patterns  within  a  record  (e.g.,  beginning  of  line 
patterns  not  at  the  beginning  of  the  pattern  like  ' a , 
extra  patterns  after  an  end  of  line  pattern  like  '$a*',  and 
multiple  closures  like  '&**')  can  be  incorrect.  PatfromRec 
detects  single  pattern  errors  while  translating  a  record 
into  a  concrete  pattern  object;  and  MatchPat  detects  errors 
arising  from  the  contextual  use  of  a  pattern  while  pattern 
matching.  We  made  this  distinction  because  we  found  that 
PatfromRec  did  not  (in  general)  distribute  with  respect  to 
concatenation,  i.e.: 

PatfromRec (R1  cat  R2)  <>  PatfromRec (Rl)  cat  PatfromRec (R2) 
For  example,  is  the  escape  character  and  is  Arb  (a 

pattern  that  matches  any  single  character) ,  but 
PatfromRec (ConcatRec ( ,"?") )  * 

PatfromRec ('Q?')  =  Lit("?") 

yieJds  a  pattern  to  match  the  literal  character  ,  while 
ConcatPat (PatfromRec ( "@" ) , PatfromRec ("?" ) )  = 

ConcatPat (ErrorPat, Arb)  =  ErrorPat 
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produces  the  error  pattern. 


MatchPat  determines  the  position  within  a  record  where 

a  pattern  matches.  The  fragment  of  the  MatchPat  definition 

shown  below  reveals  that  pattern  matching  (for  patterns 

containing  closures)  and  contextual  error  checking  (for 

beginning-of-line  patterns  within  larger  patterns)  is 

performed  by  looking  ahead  at  the  next  pattern  in  P.  For 

example,  if  the  first  subpattern  of  P  is  an  Arb,  MatchPat 

looks  ahead  at  the  next  piece  of  the  pattern: 

FirstPat (Restof Pat (P) )  for  Arb 

FirstPat (RestofPat (Restof Pat (P) ) )  for  Arb*  and  fails  the 

match  (returns  0)  if  a  beginning-of-line  pattern  is  found. 

If  this  were  not  done,  MatchPat  would  fail  to  recognize  that 

the  internal  beginning-of-line  pattern  was  not  the  first 

subpattern  of  P  because  of  the  recursive  style  of  the 

definition. 

MatchPat (R,P)  - 
if  IsNullPat (P) 

then  1  /*  a  Null  pattern  always  matches  */ 
else  if  IsEr rorPat (P) 

then  0  /*  error  patterns  never  match  */ 
else  if  IsEol (Fir stPat (P) ) 

then  /*  End  of  Line  */ 

•  •  • 

else  if  IsBol (Fir stPat (P) ) 

then  /*  Beginning  of  Line  */ 

•  •  • 

else  if  IsArb (FirstPat (P) ) 

then  /*  Arb  matches  any  character  */ 

IT  IsClosure (Fir stPat (Restof Pat (P) ) ) 
then  /*  Arb*  */ 

if  IsBol (Fir stPat (Restof Pat (Restof Pat (P) ) ) ) 
then 

/*  interior  Bol,  no  match  possible  */ 

else 

if  IsNull(R)  /*  null  record  */ 
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.or.  MatchPat (Rest (R) ,P)  a  0 

/*  pattern  doesn't  match  record  */ 
then  /*  Arb*  matches  null  record  */ 

/*  record  with  rest  of  pattern?  */ 
MatchPat (R,RestofPat (Restof Pat (P) ) ) 
else  1  /*  Arb*  starts  match  here  */ 
else  /*  Arb  */ 

Tf  IsBol (FirstPat (Restof Pat (P) ) )  .or . 

/*  interior  Bol?  */ 
IsNull(R)  •  ot_.  /*  null  record  */ 

MatchPat (Rest (R) ,RestofPat (P) )  =  0 

/*  rest  of  pattern  doesn't 
*  match  rest  of  record  */ 
then  0  /*  no  match  */ 
else  /*  Arb  matches  First(R)  only 
*  if  rest  of  match  OK  */ 

MatchPat (Rest (R) , Restof Pat (P) ) 


The  MatchPat  axiom  is  unusual  in  that  its  left  side  is 

not  a  composition  of  operations  on  records  and  patterns. 

Instead  of  breaking  down  operations  by  composing  them  on  the 

left  side  of  the  axiom,  the  MatchPat  definition  recursively 

decomposes  the  pattern  on  the  right  side  of  the  axiom  using 

FirstPat  and  RestofPat.  We  would  normally  have  tried  to 

write  an  axiom  like: 

MatchPat (R,ConcatPat (Pi , P2) )  = 

if  MatchPat (SubRec (R, MatchPat (R,P1) 

+MatchLen (R, PI) ,1000) ,P2)  =  1 
then  MatchPat (R, PI) 
else  ? 

to  indicate  that  if  the  second  oart  of  the  pattern  matched 
the  part  of  the  record  after  that  matched  by  the  first  part, 
the  result  is  the  point  at  which  the  first  pattern  matched. 
However,  the  term: 

MatchPat (naa",ConcatPat( "a*", "a") ) ) 
presents  difficulty  since  "a*"  matches  the  entire  record  and 


none  of  the  record  remains  to  match  the  final  "a".  A 
recursive  definition  could  be  written  to  handle  this  problem 
by  specifying  right-to-left  pattern  matching  while  reducing 
the  amount  of  the  record  matched  by  the  first  pattern  until 
a  match  is  found  for  the  second  pattern.  However,  even  this 
scheme  is  not  satisfactory  since  the  term: 

MatchPat ( "abcaba" ,ConcatPat ( "ab"  ,  "a") ) 
would  match  the  first  "ab"  and  the  last  "a"  instead  of  the 
second  "ab"  and  the  last  "a". 

Two  implementation  biases  occur  in  our  specification  of 
pattern  matching  operations.  First,  the  ValofChoice 
function  converts  a  (concrete  representation  of  a)  choice 
pattern  into  a  record  containing  a  list  of  characters  for 
later  use.  The  axiom  relating  ValofChoice  and  Choice  is 
representationally  biased  in  that  it  specifies  that  the  list 
of  resulting  characters  is  sorted  (via  Sor tedCharSet)  and 
that  the  underlying  representation  of  alphabetic  characters 
is  contiguous. 

Second,  we  require  the  characters  in  a  choice  pattern 
to  be  sorted  so  that  the  equality  operations  for  patterns 
can  be  specified  without  additional  hidden  functions.  The 
concrete  representations  of  choice  patterns  are  converted  to 
sorted  records  of  characters  by  ValofChoice  and  choice- 
pattern  equality  can  be  reduced  to  record  equality.  An 
alternate  approach  would  have  used  ConcatRec  to  build  an 


unocdered  record  containing  the  characters  in  the  choice 

pattern  and  to  introduce  a  hidden  function,  AllAreln,  to 

check  that  all  the  characters  of  its  first  argument  were 

contained  in  its  second  argument.  Given  two  choice  patterns 

Cl  and  C2,  the  axioms  describing  these  operations  would  be: 

PatternEqual (Cl ,C2)  *  /*  Cl  and  C2  are  Choice  patterns  */ 
AllAreln (ValofChoice (Cl) , ValofChoice (C2) )  .and . 

AllAreln (ValofChoice (C2) , ValofChoice (Cl) ) ; 

AllAreln (R1,R2)  =  /*  Rl  and  R2  are  records  */ 
if:  IsNull  (R2) 

then  true  /*  every  char  in  R2  is  in  R1I  */ 
else  MatchRec(Rl,First(R2) )  <>  0  .and. 

A1 lAr  eIn(Rl,Rest(R2) ) ; 

where  MatchRec  returns  the  location  of  its  second  argument 
in  its  first. 

5..  2.^4.  Editor 

The  editor  module  was  not  implemented  as  a  type  with  a 
concrete  representation  as  the  other  modules  were,  but  as  a 
module  providing  operations  on  files  of  records.  Its  axioms 
describe  how  to  interpret  records  as  editor  commands  to  be 
applied  to  a  file  of  text.  Since  we  did  not  anticipate 
using  the  editor  module  functions  in  any  other  module,  we 
felt  less  restraint  about  the  number  of  hidden  functions 
that  we  used  in  its  specification.  These  hidden  functions 
had  two  applications:  parsing  the  commands  (i.e.,  extracting 
an  address  field  and  basic  command  from  a  record) ,  and 
applying  them  to  the  text  file  (i.e.,  positioning  the  text 
file  and  applying  the  basic  command  throughout  an  address 


We  were  surprised  with  the  number  of  times  that  we  used 
the  underlying  types  to  specify  and  implement  the  editor 
functions  (e.g.  the  pattern  matching  functions  were  useful 
in  extracting  addresses  from  commands) .  This  differs  from 
our  usual  experience  of  building  new  types  that  merely 
manipulate  the  underlying  types  without  using  their 
operations  to  any  real  advantage. 

2-2*  Implementation  Experience 

The  following  table  shows  the  sizes  of  the  different  pieces 
of  the  system. 


module 

code 

axioms 

testdata 

functions 

axioms 

name 

lines 

lines 

lines 

count 

count 

editor 

241 

220 

75 

9 

8 

files 

254 

145 

68 

18 

34 

patterns 

877 

881 

181 

29 

143 

records 

186 

164 

57 

19 

26 

totals 

1558 

IBlHiBI 

381 

75 

211 

Although  the  number  of  lines  of  axioms  and  the  number  of 
axioms  looks  forbidding,  many  axioms  were  trivial.  The 
pattern  module  had  9  primitive  functions  (basic  pattern 
types)  and  eight  functions  for  discriminating  among  them. 
Thus  72  of  the  143  axioms  looked  like: 

Is  Primitive  Patternl (Primitive  Pattern2)  *  false 
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Specification  Problems 

We  chose  to  implement  the  text  editor  from  [Kernighan  and 
Plauger  81]  because  it  was  a  well-known,  carefully 
documented  problem.  Nevertheless,  we  encountered  several 
difficulties  with  the  informal  documentation.  No 
association  rule  was  given  for  ranges,  so  the  pattern  [a-c- 
e]  '  could  be  interpreted  as  [abce@-] ,  [acde@-] ,  or  even  ta¬ 
el  .  Also  their  informal  documentation  did  not  explain  when 
the  editor's  "current  position"  is  moved  during  command 
interpretation.  Consider  the  editor  command: 

\begin\, /end/p 

and  the  file: 
begin 

write('This  write  contains  the  word:  end') 

/*  other  text  here  */ 

x  :■  1  /*  "current  position"  of  the  editor  here  */ 

end 

If  the  fourth  line  is  the  "current  position"  of  the  editor, 
the  forward  search  for  the  "end"  pattern  could  start  from 
the  "current  position"  or  from  the  position  found  by  the 
backward  search  for  the  pattern  "begin".  Producing  formal 
specifications  made  us  consider  these  cases. 

Unit  Testing 

During  unit  testing,  we  ensured  that  the  axioms  and 
implementations  were  consistent  for  our  test  data.  In 
addition,  DAISTS'  run-time  monitors  insisted  that  we  supply 
enough  test  data  so  that  every  axiom  branch  and 
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implementation  statement  was  executed,  and  that  each 
expression  in  the  axioms  and  code  had  at  least  two  different 
values  during  testing.  Expression  coverage  at  the  95%  level 
is  easy  to  achieve  with  common  test  data,  but  each 
additional  percentage  point  of  coverage  required  great 
effort. 

There  were  a  few  expressions  in  tests  that  we  could  not 
get  to  vary.  These  expressions  fell  into  one  of  two 
categories:  either  they  were  tests  to  ensure  safe  failing 
when  the  input  arguments  were  outside  the  normal  function 
domain,  or  they  were  truly  redundant. 

An  example  of  the  safe-failing  test  occurred  when  we 
included  a  check  in  the  pattern  matching  routine  to  see  that 
the  pattern  argument  was  initialized.  Since  our  pattern 
variables  were  always  initialized,  the  outcome  of  this  test 
never  varied. 

Code  improvements  are  sometimes  foregone  because  the 
worst-case  analysis  of  algorithms  makes  it  impossible  to 
tell  if  a  certain  improvement  is  allowable.  A  compiler- 
based  tool  can  judge  both  a  program  and  its  test  data,  and 
insist  that  no  improvement  is  possible  [Hamlet  77a] .  DAISTS 
detects  these  improvements  as  expressions  that  do  not  vary 
or  statements  that  are  not  executed.  For  example,  the 
MatchLen  function  in  the  pattern  module  was  constructed  by 


copying  the  code  for  the  MatchPat  function,  and  then 
modifying  it  to  return  the  number  of  characters  matched 
rather  than  the  position  of  the  match.  Since  MatchLen  uses 
MatchPat  to  do  the  "recursive  lookahead"  necessary  for  the 
pattern  matching,  a  number  of  places  in  MatchLen  could  be 
optimized;  they  were  hold-overs  from  the  MatchPat  function 
and  could  no  longer  occur.  It  is  not  clear  whether  to 
delete  these  holdovers  in  the  name  of  efficiency,  or  to 
maintain  the  parallel  construction  for  ease  of  maintenance. 

5^.  3. 3.  Integration  Testing 

We  found  only  two  errors  during  integration  testing.  The 

routine  to  extract  subrecords  returned  a  subrecord  with  an 

extra  character  when  the  start  and  length  of  the  subrecord 

equaled  the  length  of  the  original  record.  The  original  >* 

in  the  following  code  had  to  be  changed  to  >. 

Record  func  SubRec (Record  X,  int  First,  int  Len) 

•  •  • 

if  First  +  Len  >*  Length (X.Val) 
then 

Result. Val  :=  X.Val[First] 
else 

Result. Val  :=  X.Val [First, Len] 
end 

return (Result) 

The  error  would  have  been  detected  if  we  had  used  the 
testing  criteria  in  [Howden  81]  in  which  arithmetic  relation 
functions,  El  r  E2,  must  be  evaluated  over  values  for  which 
E1<E2,  E1-E2,  and  E1>E2. 
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The  other  integration  error  occurred  in  the  routine 
that  maintained  sorted  sets  of  characters,  which  inserted 
duplicate  characters.  This  error  would  not  have  been  found 
with  any  unit  testing  strategy  because  both  the 
specification  and  the  implementation  for  the  function  were 
wrong  (in  the  same  way) .  It  was  not  until  the  module  was 
integrated  with  the  patterns  module  that  the  error  was 
detected.  After  we  realized  that  the  wrong  function  had 
been  implemented,  DAISTS  was  still  useful  in  testing  the 
corrected  specification  and  implementation.  It  is 
interesting  to  note  that  this  error  occurred  in  a  function 
introduced  to  support  the  implementation  bias  discussed 
above;  the  function  itself  did  not  provide  an  interesting 
operation. 


Jj.,4.  Conclusions  from  the  Case  Study 

The  use  of  DAISTS  in  this  case  study  must  be  considered 
successful  —  only  two  errors  escaped  unit  testing.  There 
was  only  one  instance  where  the  orthogonality  of  DAISTS' 
(applicative)  specification  language  and  its  (imperative) 
implementation  language  allowed  us  to  produce  a 
specification  and  an  implementation  that  were  both  wrong, 
and  one  other  case  where  the  implementation  and  the 
specification  disagreed  but  escaped  exposure  by  our  simple 
unit  testing  criteria. 
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As  other  researchers  have  reported,  producing  formal 
specifications  reveals  (interesting)  boundary  conditions 
that  are  often  omitted  in  even  the  most  carefully 
constructed  informal  problem  statements.  Using  the 
specifications  with  a  testing  tool  forced  our 
implementations  to  handle  these  boundary  conditions. 

The  use  of  algebraic  axioms  as  a  formal  specification 
language  was  unwieldy  for  several  of  the  functions  that  we 
implemented.  Our  specifications  contain  many  "recursive 
definitions"  that  do  not  look  like  typical  algebraic  axioms. 
The  tests  in  these  definitions  are  ordered,  making  them  more 
like  applicative  programs  than  algebraic  axioms  that 
distribute  their  tests  among  several  independent  axioms. 

Giving  up  the  independence  of  axioms  appears  to  reduce  the 

\ 

orthogonality  between  the  specification  and  the 
implementation.  [Gerhart  and  Wile  79]  report  similar 
experiences  with  the  axioms  in  the  Delta  system. 
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6 .  Conclusion 

6.1^  Advantages 

We  feel  DAISTS  has  several  advantages  over  conventional 

program  development  systems: 

(1)  The  specification,  program,  and  test  data  are  packaged 
as  a  single  entity,  encouraging  their  mutual 
maintenance. 

(2)  The  specif ication  language  is  applicative  and  the 

implementation  language  is  imperative.  This 
orthogonality  reduces  the  likelihood  of  the  same  error 
appearing  in  both  the  specification  and  the 

implementation. 

(3)  The  test  data  coverage  of  the  specification  and  the 
program  are  measured.  Thus  it  is  unlikely  that  the 
specification  makes  distinctions  that  the 
implementation  does  not,  and  vice  versa. 

(4)  There  is  no  need  to  describe  the  concrete 
representation  of  the  results  of  an  operation  in  the 
specification;  the  user  (specifies  and)  writes  an 
equality  routine  to  judge  the  results  of  tests  for 
abstract  objects.  This  simplifies  the  testing  process 
by  removing  the  requirement  for  "hand  simulation"  of 
complicated  operations. 
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(5)  Having  a  tool  that  incorporates  specifications  into  the 
development  process  should  provide  the  motivation  and 
experience  necessary  for  programmers  to  use  formal 
specifications  effectively. 

When  measured  by  the  number  of  persistent  errors  in  the 
development  of  our  text  editor,  DAlSTS's  use  must  be 
considered  successful  —  only  two  errors  were  found  during 
integration  testing.  The  orthogonality  of  DAISTS' 
specification  language  and  its  implementation  language 
resulted  in  only  one  error  for  which  both  the  specification 
and  the  implementation  were  wrong.  We  were  also  pleased  by 
the  degree  to  which  our  coverage  measures  complemented  the 
formal  specifications:  there  was  only  one  integration  error 
in  which  the  implementation  and  the  specification  disagreed 
despite  passing  both  hurdles. 

Our  classroom  experiment  showed  that  DAISTS  can  help 
users  formulate  more  effective  tests.  Axioms  are  also 
effective  for  exploring  boundary  conditions,  where  errors 
frequently  occur  [Goodenough  and  Gerhart  75] .  DAISTS  uses 
the  simplest  structural  test  criteria  imaginable,  but  it  is 
surprising  how  well  they  direct  testing.  When  a  programmer 
has  written  the  code  and  a  set  of  axioms,  and  chosen 
intuitively  appealing  test  sets,  the  module  usually  fails 
the  structural  coverage  requirements  (often  in  the  axioms 
because  of  boundary  cases) .  Data  added  to  achieve  coverage 


72 


may  then  expose  an  inconsistency  (often  that  the  boundary 
cases  were  omitted  from  the  code) .  Furthermore,  even  for 
the  simplest  modules  it  is  impossible  to  second-guess 
DAISTS"  responses:  the  bookkeeping  required  to  see  that  a 
set  of  tests  succeeds,  including  the  structural 
requirements,  can  only  be  done  accurately  by  a  computer. 
The  subjects  of  our  study  who  used  only  the  sort  program  to 
test  their  implementations  stopped  testing  too  soon  because 
the  data  they  fed  the  sort  program  did  not  expose  errors  in 
their  implementations.  Even  the  subjects  in  our  study  who 
wrote  their  own  test  drivers  exhibited  a  variety  of 
questionable  testing  practices  -  omitted  functions,  failures 
to  consider  boundary  cases,  and  generally  insufficient  test 
data. 


We  were  frustrated  by  the  imprecision  inherent  in 
informal  specifications.  In  our  experiment,  subjects 
stretched  our  careful  English  descriptions  to  restrict  their 
implementation  to  handle  only  single-digit  integers  and  to 
disallow  a  value  that  was  used  as  an  internal  marker.  We 
experienced  similar  ambiguities  with  the  informal 
specifications  in  [Kernighan  and  Plauger  81] ;  no  association 
rule  was  given  for  ranges  and  no  explanation  was  given  for 
when  the  editor  is  moved  during  command  interpretation. 
DAISTS''  formal  specifications  usually  avoid  this  imprecision 
by  forcing  explicit  enumeration  and  treatment  of  boundary 
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cases.  We  only  noticed  the  ambiguity  of  the  text  editor 
descriptions  when  we  wrote  our  algebraic  specifications. 

§_.2.  Drawbacks 

Despite  these  advantages,  DAISTS  is  not  without  flaws.  If 
there  are  no  failures,  DAISTS  reports  that  test  sets  were 
tried  without  incident.  As  in  any  testing,  this  "success" 
is  of  doubtful  significance.  The  implementation  and  axioms 
could  contain  compensating  errors;  also,  implementation  or 
axioms  alone  could  be  wrong  yet  hide  the  error  by  internal 
compensation.  It  is  our  belief  that  implementations  and 
axioms  are  unlikely  to  compensate  for  each  other's  errors 
because  of  their  orthogonal  natures.  It  is  more  likely  that 
one  description  of  the  data  type  contains  canceling  errors. 

Equality  function  implementations  are  the  most  likely 
to  contain  compensating  errors.  The  ultimate  such  error  is 
an  "equality"  which  always  returns  true  (ignorina 
differences  between  the  objects  it  was  to  have  compared) . 
Then  all  axioms  apparently  succeed  on  any  data,  no  matter 
what  the  other  function  implementations  do  (so  long  as  they 
return  values) .  A  programmer  is  not  likely  to  trivialize 
the  implemented  type  in  this  way  because  he  must  understand 
the  equality  interpretation  to  understand  the  representation 
function.  Furthermore,  the  structural  test  requirements 
often  catch  the  error  of  making  too  many  things  equal.  For 
example,  none  of  the  expressions  of  type  Stack  could  vary  if 
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Stackequal  always  returns  true  because  DAISTS  uses  this 
function  to  determine  when  an  expression's  value  has  varied. 
However,  DAISTS  must  admit  the  possibility  of  a  bad  equality 
implementation.  Consider  the  following  functions  purporting 
to  implement  "Pop",  "Push",  "Top",  and  "StackEqual"  for 
bounded  stacks: 


Stack  func  Push (Stack  S,  EltType  Elt) 

Stack  Result 

if  S.StackTop  +  1  =  StackSize 
then 

return  (S)  /*  return  stack  unchanged  */ 

end 

Result. Values (1)  :=  S.Values(O)  /*  copy  current  top  value  */ 
Result. StackTop  :=  Result. StackTop  +  1 
Result. Values (0)  :=  Elt 

return (Result) 

Stack  func  Pop (Stack  S) 

Stack  Result 
if  Empty (S) 
then 

return (S) 

end 

Result. Values (0)  :  =  S. Values (1)  /*  copy  next  to  top  elt  */ 

Result. StackTop  :=  Result . StackTop  -  1 
return (Result) 

EltType  func  Top (Stack  S) 
if  Empty (S) 
then 

return (Undefined) 

end 

return (S. Values (0) ) 

Bool  func  StackEqual (Stack  P,  Stack  Q) 
if  Depth (P)  =  Depth (Q) 
then 

if  P. Values (0)  <>  Q. Values (0) 
then 

return (False) 

end 

return  (True) 

end 

return (False) 
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The  functions  have  all  been  adjusted  to  keep  only  the 
current  and  previous  values  that  were  pushed  onto  the  stack. 
Since  none  of  the  axioms  push  more  than  one  value  or  pop 
more  than  one  value,  and  since  the  StackEqual  axiom  only 
looks  at  the  current  top  value,  no  monitoring  can  detect 
these  compensating  errors. 

The  current  version  of  the  system  requires  that  the 
parameters  of  a  function  not  be  altered  by  the 
implementation.  Otherwise  separate  occurrences  of  free 
variables  in  axioms  could  contain  different  values.  DAISTS 
also  requires  that  each  function  mentioned  in  the 
specification  be  implemented;  if  the  specification  uses 
hidden  functions,  each  of  them  must  appear  in  the 
implementation  for  the  module  to  be  tested. 

In  our  case  study  we  found  algebraic  axioms  to  be  an 
unwieldy  specification  notation  for  several  of  the  text 
editor  modules.  Problems  occurred  in  modules  that  were  not 
really  data  types  in  which  values  are  stored  and  retrieved, 
but  collections  of  related  functions  (e.g.  the  editor 
module) .  Our  specifications  contained  many  "recursive 
definitions"  which  did  not  look  like  typical  algebraic 
axioms.  Recursive  definitions  appear  imperative  while 
typical  axioms  seem  declarative:  the  order  of  the  tests  on 
the  right  sides  of  recursive  definitions  is  fixed,  while  the 
algebraic  axioms  distribute  these  tests  among  several 
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independent  axioms.  [Gerhart  and  Wile  79]  seemed  to  have 
had  similar  experiences. 

6.3.  Enhancements 

DAISTS  could  profitably  be  extended  in  several  directions: 
with  the  ability  to  manipulate  the  specifications  directly 
(so  that  they  could  be  exercised  as  rewrite  rules)  ,  with  the 
inclusion  of  other  formal  specification  languages  (that 
handle  procedures  with  side  effects  and  communication 
interfaces) ,  and  by  the  addition  of  interactive  run-time 
monitors  to  allow  construction  of  test  sets  to  extend 
coverage  incrementally. 

We  feel  that  DAISTS-like  systems  might  expose  some 
additional  errors  with  more  stringent  structural  criteria 
like  special-values  testing  strategies  [Howden  78]  (e.g., 
adding  tests  that  include  the  constants  of  the  types  and  the 
those  that  appear  in  the  text  of  the  implementation)  and 
functional  testing  [Howden  81J  (e.g.,  evaluating  arithmetic 
relation  functions,  El  r  E2,  over  values  for  which  El<E2, 
El=E2,  and  E1>E2) .  This  enhanced  structural  criteria  would 
have  exposed  residual  errors  that  we  discovered  in  our 
subjects'  programs  and  in  our  editor  implementation.  The 
desire  for  such  additional  measures  must  be  balanced  against 
the  difficulty  of  achieving  them.  During  unit  testing  of 
the  text  editor,  we  found  expression  coverage  at  the  95% 
level  easy  to  achieve  with  common  test  data,  but  each 
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additional  percentage  point  of  increased  coverage  required 
great  effort. 


The  computer  science  community  has  a  growing  consensus 
on  the  desirability  of  formal  specifications.  Writing 
formal  specifications  would  not  be  considered  an  overhead 
activity  if  they  could  be  used  to  reduce  the  effort  of 
writing  and  testing  implementations.  A  tool,  such  as 
DAISTS ,  which  can  incorporate  formal  specifications  into  the 
development  process  could  provide  the  motivation  and 
experience  necessary  to  produce  those  specif ications. 
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8.1.  First  page  of  assignment 

You  are  to  write  the  CLASS  implementation  for  lists  of 
integers.  A  list  is  an  ordered  collection  of  elements  that 
may  have  elements  added  and  deleted  at  its  ends,  but  not  in 
its  middle.  The  operations  that  you  must  "export"  are: 
AddFirst,  AddLast,  Cone,  DeleteFirst,  DeleteLast,  First, 
IsEmpty,  i.istEqual,  ListLength,  NewList,  and  Reverse.  Each 
operation  is  described  in  detail  below. 

The  lists  are  to  contain  up  to  eleven  (11)  elements.  If 
an  element  is  added  to  the  front  of  a  "full"  list  (one 
containing  eleven  elements  already) ,  the  element  at  the  back 
of  the  list  is  to  be  discarded.  Elements  to  be  added  to  the 
back  of  a  full  list  are  discarded.  Requests  to  delete 
elements  from  empty  lists  result  in  empty  lists,  and 
requests  for  the  first  element  of  an  empty  list  results  in 
zero  (0) . 

Remember  that  the  operations  that  you  implement  are  to 
be  functions,  and  that  they  may  ***NOT***  change  their 
parameters!  If  a  function  needs  to  manipulate  a  parameter  to 
perform  the  operation,  the  parameter  is  to  be  COPIED  to  a 
LOCAL  variable  BEFORE  the  change  is  performed!  You  may  use 
any  representation  you  choose  to  implement  your  lists.  The 
detailed  operation  descriptions  are  below: 


List  FUNC  Addf irst (List  L, INT  I)  -  Returns  the  list  with 
I  as  its  first  element  followed  by  the  elements  of  L. 
If  L  is  "full"  to  start,  L's  last  element  is  ignored. 

List  FUNC  Addlast(List  L , INT  I)  -  Returns  the  list  with 
the  elements  of  L  followed  by  I .  If  L  is  full  to 
start,  I  is  ignored. 

List  FUNC  Conc(List  LI, List  L2)  -  Returns  the  list  made 
up  of  the  elements  of  list  LI  followed  by  the  elements 
of  L2.  If  LI  and  L2  together  contain  more  than  eleven 
(11)  elements,  then  the  extras  are  to  be  ignored. 

List  FUNC  Deletef irst (List  L)  -  Returns  the  list 
containing  all  but  the  first  element  of  L.  If  L  is 
empty,  then  it  returns  an  empty  list. 

List  FUNC  Deletelast (List  L)  -  Returns  the  list 
containing  all  but  the  last  element  of  L.  If  L  is 
empty,  then  it  returns  an  empty  list. 
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INT  FUNC  First(List  L)  -  Returns  the  first  element  in  L. 
If  L  is  empty,  then  it  returns  zero  (0) . 

INT  FUNC  Isempty(List  L)  -  Returns  one  (1)  if  L  is  empty, 
zero  (0)  otherwise. 

INT  FUNC  Listequal {List  LI, List  L2)  -  Returns  one  (1)  if 
the  two  lists  are  element  for  element  equivalent  (e.g. 
First(Ll)  =  Fir st (L2) , . . . ) ,  and  zero  (0)  otherwise. 
Note  that  two  empty  lists  are  considered  equal. 

INT  FUNC  Listlength (List  L)  -  Returns  the  count  of 
elements  in  L.  An  empty  list  has  a  count  of  zero  (0) 
elements. 

List  FUNC  Newlist  -  Returns  a  list  initialized  to  be 
empty 

List  FUNC  ReversefList  Ll)  -  Returns  a  list  containing 
the  elements  of  Ll  in  reverse  order. 
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8.2.  Second  page  of  assignment  (control  group) 


A  test  routine  has  been  written  for  you,  or  you  may 
write  your  own  test  routines.  The  provided  routine  reads  in 
groups  of  integers,  sorts  them,  and  prints  out  the  smallest 
11  of  each  group.  The  test  routine  expects  the  groups  of 
integers  to  be  separated  by  zero.  A  sample  test  run  using 
the  provided  test  routine  is  shown  below: 


@add  simpld*pro ject . setup  <done  once  per  run> 


@$ . SIMPLD , S  •  <calls  the  compiler, 

asks  for  listing> 

<list  implementation>  <your  CLASS  for  lists> 

$TEST  <causes  the  test 

routine 

to  be  provided> 

<groups  of  integers,  separated  by  zeros> 

@eof  <end  of  the  data> 

The  data  for  the  test  routine  may  have  any  number  of 
integers  or  groups  of  integers  per  card,  with  the  integer  0 
separating  each  group.  Spaces  are  used  to  separate  the 
integers  when  more  than  one  integer  is  on  a  card. 

A  sample  run  f  .  using  your  own  test  routine  is  shown 
below : 

9$. SIMPLD, S 
above , 

done> 

<list  implementation> 

<your  test  driver> 

$DATA 

<your  data> 

@eof 

You  will  be  required  to  submit  your  list  implementation  via 
the  deck  submission  processor  (to  be  discussed  in  class), 
and  you  will  also  turn  in  a  listing  of  a  run  using  the 
provided  test  routine,  that  shows  several  groups  of  integers 
correctly  sorted. 


<call  compiler  as 

assuming  setup  is 
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8. 2*  Second  page  of  assignment  (axiom  group) 

Axioms  have  been  written  that  you  must  use  to  debug 
your  CLASS.  You  may  add  axioms  of  your  own  at  your 
discretion.  A  sample  run  is  shown  below: 


@add  simpld*project . setup 


@$ . SIMPLD / S 

<list  implementation> 

$ AXIOMS 
provided> 

<your  optional  axioms> 

TESTPOINTS 

<your  testpoints> 

TESTSETS 

<your  testsets> 

START 

@eof 


<done  once  per  run> 


<calls  compiler,  asks 
for  listing> 

<your  CLASS  for  lists> 
<causes  axioms  to  be 


<that's  all  you  need> 


You  will  be  required  to  submit  your  list  implementation 
via  the  deck  submission  processor  (to  be  discussed  in 
class) ,  and  you  will  also  turn  in  a  listing  of  a  run  using 
the  provided  axioms,  with  no  axiom  failures  and  all 
statements  executed. 


UNCLASSIFIED 

2  of  2  I 


marylano  univ  college  park  dept  of  COMPUTER  SCIENCE  F/G  9/2 

DAISTS  -  A  SYSTEM  FDR  USING  SPECIFICATIONS  AND  VERIFICATIONS  TO— ETC<U> 
JUN  82  P  R  MCMULLIN  F49620-80-C-0001 

AFOSR-Tr-82-0867  NL 


Appendix  II  -  The  Axioms  supplied  to  the  axiom 


9.  Appendix  II  -  The  Axioms  supplied  to  the  axiom  grouo 
Axioms 


/*  These  axioms  are  constructed  following  the  Guttag 

rules  for  deciding  which  axioms  need  to  be  constructed. 
The  functions  in  the  "0"  group  are: 

IsEmpty,  ListEqual,  ListLength,  First 
The  functions  in  the  "TOIl"  group  are: 

NewList,  AddFirst 

The  functions  in  the  "T0I2"  group  are: 

AddLast,  DeleteLast,  DeleteFirst,  Cone,  Reverse 


IsEmptyl: 

IsEmpty (NewList)  *  1; 


IsEmpty2 (List  AxListl , int  Axlntl) : 

IsEmpty (AddFirst (AxListl ,AxIntl) )  *  0; 


ListEqual 1 : 

ListEqual (NewList, NewList)  *  1; 

ListEqual2 (List  AxListl , int  Axlntl): 

ListEqual (NewList, AddFirst(AxListl, Axlntl) )  *  0; 

ListEqual3 (List  AxListl , int  Axlntl): 

ListEqual (AddFirst (AxListl , Axlntl) , NewList)  *  0; 

ListEqual4 (List  AxListl, List  AxList2 , int  Axlntl , int  Axlnt2) : 
ListEqual (AddFirst (AxListl , Axlntl) , AddFir st (AxList2 , Axlnt2)  ) 

a 

if  Axlntl  <>  Axlnt2 
then  0 
else 

if  ListLength (AxListl)  *  11 

then  /*  Need  to  trim  the  end  off!  */ 

ListEqual (DeleteLast (AxListl) , DeleteLast (AxList2) ) 
else  /*  Compare  them  just  as  they  are!  */ 

ListEqual (AxListl ,AxList2) ; 


ListLengthl : 

ListLength (NewList)  *  0; 

ListLength2 (List  AxListl , int  Axlntl): 

ListLength (AddFir st (AxListl , Axlntl) )  * 
i f  ListLength (AxListl)  *  11 
then  11 

else  1  +  ListLength (AxListl) ; 
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Pirstl: 

First (NewList)  3  0; 

First2(List  AxListl , int  Axlntl) : 

First(AddFirst(AxListl, Axlntl) )  3  Axlntl; 


/*  Now  for  the  "TOI2"  function  definitions:  */ 
AddLastl (int  Axlntl): 

AddLast (NewList, Axlntl)  3  AddFirst (NewList, Axlntl) 

AddLast2 (List  AxListl , int  Axlntl, int  Axlnt2) : 

AddLast (AddFirst (AxListl , Axlntl) , Axlnt2)  3 
AddFirst (AddLast (AxListl ,AxInt2) , Axlntl) ; 


DeleteLastl : 

DeleteLast (NewList)  3  NewList; 

DeleteLast2 (List  AxListl, int  Axlntl): 

DeleteLast (AddFirst (AxListl , Axlntl) )  3 
if  IsEmpty (AxListl) 
then  NewList 
else 

if  ListLength (AxListl)  3  11 
then 

AddFirst (DeleteLast (DeleteLast (AxListl) ) , Axlntl) 

else  AddFirst (DeleteLast (AxListl) , Axlntl)  ; 


DeleteFir stl : 

DeleteFir st (NewList)  3  NewList; 

DeleteFir st2 (List  AxListl , int  Axlntl): 

DeleteFirst (AddFirst (AxListl , Axlntl) )  3 
if  ListLength (AxListl)  3  11 
then  DeleteLast (AxListl) 
else  AxListl; 


Concl(List  AxListl): 

Cone (NewList, AxListl)  3  AxListl; 

Conc2(List  AxListl, List  AxList2 , int  Axlntl): 
Cone (AddFirst (AxListl , Axlntl) ,AxList2)  3 
AddFirst (Cone (AxListl ,AxList2) , Axlntl) ; 


Reversel : 

Reverse (NewList)  3  NewList; 
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Reverse2 (List  AxListl , int  Axlntl) : 

Reverse ( AddFir st (AxListl , Axlntl) )  * 
if  ListLength (AxListl)  3  11 

then  AddLast (Reverse (DeleteLast (AxListl) ) , Axlntl) 
else  AddLast (Reverse (AxListl) , Axlntl) ; 
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10.  Appendix  III  -  The  sort  routine  for  the  control  group 


proc  Main  /*  The  driver  for  the  sort  program  to  test 
lists.  */ 

/*  Read  in  a  series  of  numbers  that  ends  with  zero,  sort 
them,  */ 

/*  and  then  print  out  the  smallest  "ListSize"  of  them.  */ 

int  Holder  /*  A  place  to  read  numbers  into  */ 
int  Setnumber  /*  The  number  of  the  current  set  */ 
int  Counter  /*  A  counter  of  the  number  of  numbers  in 
Unsorted  */ 

List  Unsorted  /*  Where  the  unsorted  numbers  are  read  into  */ 
List  Sorted  /*  Where  the  sorted  numbers  are  stored!  */ 

/*  Main  loop  for  reading  in  sets  of  numbers  */ 

Setnumber  :*  1  /*  Start  to  work  on  the  first  set  */ 
while  .not,  eoi  do 

Sorted  NewList  /*  No  sorted  numbers  in  this  group  */ 
Unsorted  :*  NewList  /*  Also  no  unsorted  numbers  in  vet! 

*/ 

read (Holder)  /*  To  initialize  Holder!  */ 

while  Holder  <>  0  .and. 

.not,  eoi  do  7*  Keep  reading  and  sorting  */ 
Counter  :=~(J  /*  Set  to  count  the  unsorted  list  */ 

while  Holder  <>  0  .and. 

Counter  <  ListSize  .and.  .not,  eoi  do 
Unsorted  :*  AddFirst (Unsorted, Holder) 

Counter  :=»  Counter  +  1 

read (Holder)  /*  Get  the  next  number  of  the 

set  */ 

end 

/*  Either  Unsorted  is  full,  or  this  set  is 
finished!  */ 

/*  Must  first  join  unsorted  numbers  with  sorted 

ones  V 

Sorted  :*  Merge (Sorted, Sort (Unsorted) ) 

end 

/*  Here  we  must  have  hit  an  end  of  a  set!  */ 

/*  Print  out  the  first  "ListSize"  worth  of  numbers  */ 

write (skip, "Sorted  numbers  of  set  number ', Setnumber) 
while  .not.  IsEmpty (Sorted)  do 

write (First (Sorted) )  /*Output  smallest  number  in 

set*/ 

Sorted  :»  DeleteFirst (Sorted) 

end 
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Setnumber  :*  Setnumber  +  1  /*  Now  start  the  next  set  */ 
end  write  (skip,sk  ip  , skip,  ''Out  of  sets  of  numbers  to  sort") 


List  func  Merge (List  Mlin,List  M2in)  /*Merges  two  sorted 

lists*7 

List  Result 

List  Ml, M2  /*  Locals  so  that  we  do  not  change  the 
parameters!  */ 

Ml  :=  Mlin  /*  Copy  parameter  */ 

M2  :*  M2in  /*  Copy  second  parameter  too!  */ 

Result  :*  NewList 

while  .not.  (IsEmpty(Ml)  .or..  IsEmpty(M2)) 
do  /*  Done  when  one  is  empty!  */ 
if  First(Ml)  <*  First(M2) 

then  /*  Take  next  value  from  Ml  */ 

Result  :*  AddFirst(Result,First(Ml) ) 

Ml  :*  DeleteFirst (Ml)  /*  Don't  need  first  number 

*/ 

else  /*  Take  from  M2!  */ 

Result  :*  AddFirst(Result,First(M2) ) 

M2  :*  DeleteFirst(M2)  /*  Discard  first  after 

copying  */ 
end 

end 

/*One  of  the  two  lists  is  empty  -  catenate  them  all 
together ! */ 

return (Cone (Reverse (Result) , Cone (Ml , M2) ) )  /*and  reorder 
Result ! V 


rec  List  func  Sort(List  Inlist)  /*Sorts  into  increasing 
order*/ 

/*  This  procedure  works  by  a  merge  sort  -  Split  the  list  in 
*/ 

/*  two,  sort  each  half,  and  then  merge  the  two  sorted  halfs! 
V 

List  Half 1 , Half 2 

Halfl  :*  NewList  /*  Initialize!  */ 

Half2  !■  Inlist  /*  Initialize!  */ 
while  ListLength (Half 1)  <  ListLength (Half 2)  do 
Halfl  AddFirst(Halfl,First(Half2) ) 
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Half2  :*  DeleteFirst (Half 2) 
end  return (Merge (Sort (Half 1) , Sort (Half 2) ) ) 
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11.  Specifications  from  the  Case  Study 
define  true  *  "1",  false  *  'O',  NullChar  = 
11. 1.  Axioms  forRecords 
RecLength 0 : 

RecLength (NullRec)  *  0; 

RecLengthl (Record  A,  Record  B) : 

RecLength (ConcatRec (A, B) )  *  RecLength(A) 

RecLength 2  (char_  X)  : 

RecLength (RecofChar (X) )  * 
i_f  X  <>  NullChar 
then  1 
else  0; 


IsNullO; 

IsNull (NullRec)  *  true? 

IsNulll (Record  A,  Record  B) ; 

IsNull (ConcatRec ( A, B) )  -  IsNull (A)  .and. 

IsNull2 (char  X) : 

IsNull (RecofChar (X) )  *  X  *  NullChar; 


FirstO : 

First (NullRec)  *  NullRec? 

Firstl (Record  A,  Record  B)  : 
First(ConcatRec(A,B) )  ■ 
i_f  IsNull  (A) 
then  First(B) 
else  First (A) ; 


First2 (char  X)  ; 

First (RecofChar (X) )  ■  RecofChar (X) ; 


CharofRecO : 

CharofRec (NullRec)  ■  NullChar? 

CharofRecl (Record  A,  Record  B) : 
CharofRec (ConcatRec (A, B)  )  ■ 
if  IsNull (A) 

then  CharofRec (B) 
else  CharofRec (A) ? 


“charval (0)  " 


+  RecLength (B) 


IsNull (B) ? 
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Charof Rec2 (char  X) : 

CharofRec (RecofChar (X) )  «  X; 


Hg s tO « 

Rest (NullRec)  »  NullRec; 

Restl (Record  A,  Record  B) : 

Rest (ConcatRec (A, B) )  * 

if  IsNull (A) 
then  Rest(B) 

else  ConcatRec (Rest (A) ,B) ; 
Rest2 (char  X) : 

Rest (RecofChar (X) )  »  NullRec; 


RecordEquall (Record  A,  Record  B) : 

RecordEqual ( A,B)  * 
if  IsNull (A) 
then  IsNull (B) 
else  if  IsNull (B) 
then  false 

else  CharofRec (A)  *  CharofRec (B)  .and. 

RecordEqual (Rest (A) .Rest (B) ) ? 


RecofStringl (string  A): 

Recof String (A)  » 

if  A  *  " 

then  NullRec 
else  if  Length (A)  >  1 
^  ^  ^ 

— ConcatRec (RecofChar (charf (A) ) ,Recof String (At  2] ) ) 
else  RecofChar (charf (A) ) ; 


Str ingof Reel (Record  X) : 
Str ingofRec (X)  ■ 
if  IsNull (X) 
then  " 

else  CharofRec (X) 


.con.  StringofRec(Rest(X) ) ; 


SubRecl (Record  A,  int  X,  int  Y) t 
SubRec(A,X,Y)  - 
if  X  >  1 

then  SubRec (Rest (A) ,X-1,Y) 
eTse  if  Y  >  0 

tFen~  ConcatRec (First (A) .SubRec (Rest (A) ,X,Y-1) ) 
else  NullRec; 


Appendix  IV  -  Specifications  from  the  case  study 


MatchRecl (Record  A,  Record  B) : 

MatchRec (A, B)  ■ 

if  RecLength (A)  <  RecLength(B)  .o£.  IsNull(B) 
then  0 

else  if  RecordEqual (SubRec(A, 1, RecLength (B) ) ,B) 
then  1 

else  i f  MatchRec(Rest (A) ,B)  <>  0 
tKen  1  +  MatchRec (Rest (A) ,B) 
else  0 ; 


EscapedFindl (Record  X,  char  A,  char  B) : 

EscapedFind(X,A,B)  * 
if  IsNull(X) 
then  0 

else  if  CharofRec(X)  *  A 
then  1 

else  if  CharofRec(X)  *  B 

tKen  i f  EscapedFind (SubRec (X, 3, 1000) ,A,B)  <>  0 
then  2  +  EscapedFind (SubRec (X , 3 , 1000) , A, B) 
else  0 

else  if  EscapedFind (SubRec (X, 2 , 1000) , A, B)  <>  0 
then  1  +  EscapedFind (SubRec (X, 2 , 1000) , A, B) 
else  0; 


SortedCharSetl (char  C,  Record  X): 

SortedCharSet(C,X)  * 
if^  C  *  NullChar 
then  X 

else  if  IsNull(X) 
then  RecofChar(C) 
else  if  CharofRec(X)  <  C 

tKen 

ConcatRec (First (X) ,  Sor  tedCharSet (C,Rest (X) ) ) 
else  if  CharofRec(X)  ■  C 

tKen  X  /*  don't  duplicatel  */ 
else  ConcatRec (RecofChar (C) ,X) ; 


IntvalofRecl (Record  A): 

IntvalofRec(A)  »  IntvalHelp ( Ar 0) ; 

IntvalHelpl (Record  A,  int  I): 

IntvalHelo (A, I)  ■ 
i f  IsNull(A)  .or . 

(MatchRec (Recof String ( ' 0123456789') , Fir st (A) )  *  0) 
then  I 
else 

IntvalHelp (Rest (A) , 

I *10+MatchRec (Recof String ('123456789') , First (A) ) ) j 
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FirstisDigitl (Record  R) : 

FirstisDigit (R)  * 
if  IsNull(R) 
then  false 
else 

(Charof Rec (R)  >*  "0"  .and.  CharofRec(R)  <*  "9"); 


FirstisAl (char  A,  Record  R) : 

/*  reverse  parameters  to  use  existing  test  sets  */ 
FirstisA (R, A)  * 
if  IsNull(R) 
then  false 

else  CharofRec(R)  »  A; 
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11.2.  Axioms  for  Files 
AttopO : 

Attop (NewFile)  *  true; 

Attopl (Record  R,  Files  X): 

Attop(Insert(R,X) )  *  false; 

Attop2 (Files  X); 

/*  Delete  the  record  backed  over!  * / 

Attop (Back (X) )  *  Attop (Delete (X) ) ; 

AtendO ; 

Atend (NewFi le)  *  true; 

Atendl (Record  R,  Files  X): 

Atend ( Insert (R,X) )  *  Atend(X); 

Atend2 (Files  X): 

Atend (Back (X) )  3  IsEmpty(X); 

CurrentRecO ; 

Cur rentRec (NewFile)  3  NullRec; 

CurrentRecl (Record  R,  Files  X): 

CurrentRec(Insert(R,X) )  3  R; 

CurrentRec2 (Files  X); 

Cur rentRec (Back (X) )  3 
if  Attop (Back (X) ) 
then  NullRec 

else  CurrentRec (Delete (X) ) ;  /*  get  rid  of  a  rec  */ 

CurrentAddressO: 

CurrentAddress (NewFile)  3  0; 

CurrentAddressl (Record  R,  Files  X): 

CurrentAddress (Insert (R,X) )  3  Cur r entAddress (X)  +  1; 

CurrentAddress2 (Files  X): 

CurrentAddress  (Back  (X)  )  3  _if  Attop  (X) 
then  0 

else  CurrentAddress (X)  -  1; 

Fir stRecO : 

FirstRec (NewFile)  3  NullRec; 

FirstRecl (Record  R,  Files  X); 

FirstRec(Insert(R»X) )  3 
if  Attop (X) 
then  R 
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else  FirstRec(X); 

FirstRec2 (Files  X) : 

Fir stRec (Back (X) )  =  FirstRec(X); 

FilesLengthO : 

FilesLength (NewFile)  =  0; 

Fi lesLengthl (Record  R,  Files  X): 

FilesLength (Insert (R,X) )  =  1  +  Fileslength (X) ; 

FilesLength2 (Files  X): 

FilesLength (Back (X) )  *  Fileslength (X) ; 

IsEmptyO : 

IsEmpty (NewFile)  =  true; 

IsEmptyl (Record  R,  Files  X); 

IsEmpty (Insert(R,X) )  =  false; 

IsEmpty2 (Files  X); 

IsEmpty (Back (X) )  ■  IsEmpty (X); 

AdvanceO : 

Advance (NewFile)  =  NewFile; 

Advancel (Files  X); 

Advance (3ack (X) )  =  i_f  Attop(X) 
then  Advance(X) 
else  X; 

Advance2 (Record  R,  Files  X): 

Advance ( Insert (R,X) )  =  rf  Atend(X) 
then  Insert (R,X) 

else  Insert  CurrentRec (Advance (X) )  , 
Replace(R,Advance(X) ) ) ; 

FilesEquall (Files  X,  Files  Y) ; 

FilesEqual (X,Y)  * 
if  At top (X) 

then  if  Attop(Y) 
then  if  IsEmpty (X) 
then  IsEmpty (Y) 
else  if  IsEmpty (Y) 
then  false 

else  FilesEqual (Advance(X) ,Advance(Y) ) 
else  false 
else  if  Attop(Y) 
then  false 

else  if  RecordEqual (CurrentRec (X) , Cur rentRec (Y) ) 
then  FilesEqual (Delete (X) , Delete (Y) ) 
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else  false; 

ReplaceO (Record  R) : 

Reolace(R, NewFile)  *  NewFile; 

Replacel (Record  Rl,  Record  R2,  Files  X): 

Replace (Rl, Insert (R2 ,X) )  *  Inser t (Rl ,X) ; 

Replace2 (Record  R,  Files  X): 

Replace (R, Back (X) )  * 
if  Attop (Back  (X) ) 
then  Back (X) 
else 

Back (Insert (Cur rentRec (X) , Replace (R, Delete (X) ) ) ) 


DeleteO : 

Delete (NewFi le)  *  NewFile; 

Deletel (Record  R,  Files  X): 

Delete (Inser t (R,X) )  =  X; 

Delete2 (Files  X) : 

Delete (Back  (X) )  = 
if  Attop (Back (X) ) 
then  Back (X) 

else  Back (Insert (Cur rentRec (X) , Delete (Delete (X) ) ) ) 

Nthl  (Files  X,  injt  N)  : 

Nth (X,N)  * 
if  N  <=  0 
then  X 

else  Nth (Advance (X) ,N-1) ; 


Gotol (Files  X,  int  N) : 

Goto (X ,N)  *  Nth (TopofFile (X) ,N) ; 


TopofFilel (Files  X): 

TopofFile (X)  = 
if  Attop (X) 
then  X 

else  TopofFile (Back (X) ) ; 
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11.3.  Axioms  for  Patterns 

/*  First,  five  million  silly  axioms  to  make  the  rest  of  them 

*  intelligible.  These  are  all  boring,  and  can  be  skipped  on 

*  first  and  all  subsequent  readings  except  for  the 

*  "IsChoice3"  axiom,  which  explains  (HA!)  what  a  legal 

*  choice  oattern  looks  like. 

V 


IsArbl : 

IsArb  (Pr  intPattern( ,Arb) )  ■ 

true;  /*  print  patterns  to  get  it  used!  * / 

IsArb2 : 

IsArb (Pr intPattern( ,Bol) )  ■ 

false;  /*  print  patterns  to  get  it  used!  */ 

IsArb3 (Record  R) : 

IsArb (Choice (R) )  *  false; 

TsArb4 : 

IsArb (Closure)  »  false; 

IsArb5 : 

IsArb(Eol)  *  false; 

IsArb6 : 

IsArb (ErrorPat)  »  false; 

IsArb7 (char  C) : 

IsArb (Lit (C) )  *  false; 

IsArb8 : 

IsArb (NullPat)  =  false; 

IsArb9 (Pattern  A,  Pattern  B) : 

IsArb (ConcPats (A,B) )  * 

(IsNullPat (A)  .and.  IsArb (B))  .or. 

(IsArb (A)  .and.  IsNullPat (B) ) ; 


IsBoll: 

IsBol(Arb)  -  false; 

IsBol2 : 

IsBol(Bol)  *  true; 

IsBol3 (Record  R) : 

IsBol (Choice (R) )  *  false; 
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IsBol4 : 

IsBol (Closure)  *  false; 

IsBolS: 

IsBol (Eol)  *  false; 

IsBol6 : 

IsBol (ErrorPat)  ■  false; 

IsBol 7 (char  C) ; 

IsBol (Lit(C) )  *  false; 

IsBol8 : 

IsBol (NullPat)  *  false; 

IsBol9 (Pattern  A,  Pattern  B) : 

IsBol (ConcPats (A,B) )  * 

( IsNullPat (A)  .and.  IsBol (B) )  .or. 
(IsBol (A)  .and.  IsNullPat (B) ) ; 


IsChoicel: 

IsChoice ( Arb)  *  false; 

IsChoice2 ; 

IsChoice (Bol)  *  false; 

IsChoice3 (Record  R) ; 

IsChoice (Choice (R) )  * 

if  (CharofRec (R)  <>  "[")  .or. 

MatchRec  (Recof  String  (  ,First(Rest(R)))  .or  . 

(EscapedFind (R, " ] " , )  <>  RecLength (R) ) 
then  faise  /*  its  ends  are  a  mess  */ 
else  /*  it  ends  and  start  alright,  check  middle  */ 

If  CharofRec (Rest (R) )  * 

then  /*  an  escaped  char  to  lead  off!  V 
if  RecLength (R)  *  4 

then  true  /*  just  the  escaped  char  present  */ 
else  /*  need  to  check  the  rest  of  the  choices  */ 
IsChoice (Choice (ConcatRec (RecofChar (" [") , 

SubRec (R, 4 ,1000)  ) ) ) 

else  /*  not  an  escape  char  to  lead  off...  */ 
if  CharofRec (SubRec (R, 3 , l) )  ■ 

then  /*  check  for  a  legal  range  */ 

^  RecLength (R)  <  5  .or ♦ 

CharofRec (SubRec (R, 4 , 1) )  <»  CharofRec (Rest (R) ) 
.or .  .not. 

( (CharofRec (SubRec (R, 4 , 1) )  <■  "9"  .and . 

"0H  <«  CharofRec (Rest (R) ) )  .or. 
(CharofRec(SubRec(R,4,l)  )  <=*  nZw  .and. 

"A"  <*  CharofRec (Rest (R) ) )  .or. 
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(CharofRec(SubRec (R, 4, 1) )  <-  "z"  .and. 

"a"  <■  CharofRec (Rest (R) ) ) ) 
then  false  /*  not  a  legal  rangel  */ 
else  /*  check  other  choices  if  present  */ 
Tf  RecLenqth(R)  3  5 
then  true 

else  /*  check  other  choices  */ 

IsChoice (Choice (ConcatRec ( 

RecofChar  (”[**)  ,SubRec (R, 5, 1000)  ) ) ) 
else  /*  not  a  range!  it  starts  legally!  */ 

T?  RecLength(R)  *  3 

then  true  /*  and  ends  here!  */ 
else  /*  need  to  check  other  choices!  */ 
IsChoice (Choice (ConcatRec (RecofChar (" [") , 
SubRec(R, 3,1000) ) ) ) ; 


IsChoice4 : 

IsChoice (Closure)  3  false; 

IsChoice5 : 

IsChoice (Eol)  3  false; 

IsChoice6  s 

IsChoice (Error Pat)  *  false; 

IsChoice7 (char  C) : 

IsChoice (Lit (C) )  *  false; 

IsChoice8 : 

IsChoice (NullPat)  *  false; 

IsChoice9 (Pattern  A,  Pattern  B) : 

IsChoice  (ConcPats  (A, B)  )  =* 

( IsNullPat (A)  .and.  IsChoice(B))  .or. 
(IsChoice(A)  .and.  IsNullPat (B) ) ; 


ValofChoicel ; 

ValofChoice (Arb)  *  NullRec; 

ValofChoice2 : 

ValofChoice (Bol)  *  NullRec; 

ValofChoice3 (Record  R) : 

ValofChoice (Choice (R)  )  ■ 
if  IsNegChoice (Choice (R) ) 
then 

ValofChoice (Choice (ConcatRec (RecofChar ( " [" ) , 

Rest (Rest (R) ) ) ) ) 

else  if  .not.  IsChoice (Choice (R) )  /*  check  choice!  */ 
then  NullRec  /*  Take  care  of  the  easy  ones  V 
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else  if  CharofRec(Rest (R) )  »  "<?H 

/^need  to  build  up  the  list  of  the  letters  */ 
then  /*  an  escaped  char  to  lead  off!  */ 
if  RecLength (R)  ■  4 

then  /*  just  the  escaped  char  present  */ 

SubRec { R,  3 , 1) 

else  /*  need  to  list  the  rest  of  the  choices  */ 
SertedCharSet (CharofRec (SubRec (R, 3,1)) , 

ValofChoice (Choice (ConcatRec (RecofChar (" (")  , 
SubRec (R, 4 ,1000)  )  )  )  ) 
else  if  CharofRec (SubRec (R, 3 , 1) )  * 

/5f“‘not  an  escape  char  to  lead  off...  */ 
then  /*  expand  the  legal  range  */ 
if  intval (CharofRec (Rest (R) ) )  +  1  * 
intval (CharofRec ( SubRec ( R, 4 , 1) ) ) 
then  /*  these  two  chars  are  the  ends  of  the  range  */ 
T?  RecLength (R)  =  5 

then  Recof String (CharofRec (Rest (R) )  .con. 

CharofRec (SubRec (R, 4 , 1) ) ) 
else 

SortedCharSet (CharofRec (Rest (R) ) , 

Sor tedChar Se t( Char of Rec ( SubRec (R, 4,1)  ) , 
ValofChoice (Choice (ConcatRec ( 

RecofChar ( " [") .SubRec (R, 5, 1000)  )  ) ) ) ) 
else  /*  not  at  the  ends  of  the  range  */ 

SortedCharSet (CharofRec (Rest (R) ) , 

ValofChoice (Choice (ConcatRec (RecofChar ( " [ " ) , 
ConcatRec (RecofChar (charval ( 1+ 
intval (CharofRec (Rest (R) ) ) ) ) , 

SubRec (R,  3,1000)  )  )  )  )  ) 

else  if  RecLength (R)  =  3  /*  it  starts  legally!  */ 
then  SubRec (R, 2 , 1)  /*  and  ends  here!  */ 
else  /*  need  to  check  other  choices!  */ 

SortedCharSet (CharofRec (Rest (R) ) , 

ValofChoice (Choice (ConcatRec (Recof Char ( " [" )  , 

SubRec (R, 3, 1000)  )  )  )  )  ; 

ValofChoice4 : 

ValofChoice (Closure)  =  NullRec; 

ValofChoiceS : 

ValofChoice (Eol)  =  NullRec; 

ValofChoice6 : 

ValofChoice (ErrorPat)  =  NullRec; 

ValofChoice7 (char  C) : 

ValofChoice (Lit (C) )  *  NullRec; 

ValofChoice8 : 

ValofChoice (NullPat)  *  NullRec; 
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ValofChoice9 (Pattern  A,  Pattern  B) : 
ValofChoice (ConcPats (A, B) )  * 
if  IsNullPat(A) 

then  ValofChoice (B) 
else  if  IsNullPat (B) 
tTTen  ValofChoice  (A) 
else  NullRec; 


IsNegChoicel : 

IsNegChoice (Arb)  ■  false? 

IsNegChoice2 : 

IsNegChoice (Bol)  *  false; 

IsNegChoice3 (Record  R) : 

IsNegChoice (Choice (R) )  ■ 

Charof Rec  (Rest  (R)  )  *  .and . 

IsChoice (Choice (ConcatRec (SubRec (R, 1,1) r 
SubRec (R, 3 ,1000)  )  )  )  ; 

IsNegChoice4: 

IsNegChoice (Closure)  *  false? 

IsNegChoiceS : 

IsNegChoice (Eol)  *  false; 

IsNegChoice6 : 

IsNegChoice (ErrorPat)  *  false? 

IsNeqChoice7 (char  C) : 

IsNegChoice (Lit (C) )  *  false; 

IsNegChoiceS : 

IsNegChoice (NullPat)  *  false; 

IsNegChoice9 (Pattern  A,  Pattern  B) ; 
IsNegChoice (ConcPats (A, B) )  » 

( IsNullPat (A)  .and.  IsNegChoice (B) )  .or. 
(IsNegChoice (A)  .and .  IsNullPat (B) ) ? 


IsClosurel ; 

isClosure (Arb)  ■  false? 
IsClosure2: 

IsClosure (Bol)  *  false; 

IsClosure3 (Record  R) ; 

IsClosure (Choice (R) )  ■  false? 
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lsClosure4; 

IsClosure (Closure)  -  true? 
lsClosure5 : 

IsClosure (Eol)  *  false; 
lsClosure6 ; 

IsClosure (ErrorPat)  ■  false; 

lsClosure7 (char  C) : 

IsClosurelLlt (C) )  »  false; 

IsClosure8 ; 

IsClosure (NullPat)  ■  false; 

lsClosure9 (Pattern  A,  Pattern  B) : 

IsClosure (ConcPats (A, B) )  * 

( IsNullPat (A)  .and.  IsClosure (B) )  .or. 
(IsClosure (A)  .and .  IsNullPat(B) ) ? 


isEoll : 

IsEol(Arb)  -  false; 

IsEol2: 

IsEol(Bol)  *  false; 

lsEol3 (Record  R) ; 

IsEol (Choice (R) )  -  false? 

IsEol4 : 

IsEol (Closure)  *  false; 

IsEo15 : 

IsEol (Eol)  -  true; 

ISE0I6 : 

IsEol (ErrorPat)  *  false; 

IsEo17 (char  C) : 

IsEol (Lit (C) )  -  false? 

ISE0I8 : 

IsEol (NullPat)  *  false? 

IsEol9 (Pattern  A,  Pattern  B) : 

IsEol (ConcPats (A, B) )  * 

(IsNullPat (A)  .and.  IsEol (3))  .or. 
(IsEol (A)  .and.  IsNullPat (B) ) ; 
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i 


IsErrorPatl: 

IsEr rorPat (Arb)  *  false; 

IsErrorPat2 : 

IsErrorPat (Bol)  *  false; 

IsErrorPat3 (Record  R) ; 

IsErrorPat (Choice (R) )  * 

(.not.  IsChoice (Choice (R) ) )  .and. 

( .not.  IsNegChoice (Choice (R) )) ; 

IsErrorPat4: 

IsErrorPat (Closure)  *  false; 
IsErrorPatS: 

IsErrorPat (Eol)  *  false; 

IsErrorPatS ; 

IsErrorPat (ErrorPat)  =  true; 

IsEr rorPat 7 (cha£  C) : 

IsErrorPat (Lit (C) )  =  false; 

IsEr rorPat8 : 

IsErrorPat (NullPat)  »  false; 

IsErrorPat9 (Pattern  A,  Pattern  B) : 
IsErrorPat (ConcPats (A/B)  )  * 

(IsErrorPat (A)  .or.  IsEr rorPat (B) ) ; 


IsLitl: 

IsLit (Arb)  -  false; 
IsLit2: 

IsLit (Bol)  *  false; 

IsLit3 (Record  R) : 

IsLit (Choice (R) )  =  false; 

IsLit4 : 

IsLit (Closure)  *  false; 
IsLit5: 

IsLit  (Eol)  false; 

IsLit6 : 

IsLit (ErrorPat)  »  false; 

IsLit7 (char  C) : 

IsLitTLlt(C) )  -  true; 
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IsLit8: 

IsLit (NullPat)  ■  false; 

IsLit9 (Pattern  A,  Pattern  B) : 

IsLit (ConcPats (A,B) )  ■ 

(IsNullPat(A)  .and.  IsLit(B))  .or. 
(IsLit (A)  .and.  IsNullPat (B) ) ; 


ValofLitl: 

ValofLit (Arb)  -  NullRec; 

Valof Lit2 : 

ValofLit (Bol)  *  NullRec; 

ValofLit3 (Record  R) : 

ValofLit (Choice (R) )  *  NullRec; 

Valof Lit4 ; 

Valof Lit (Closure)  *  NullRec; 
ValofLit5: 

ValofLit (Eol)  *  NullRec; 
ValofLit6j 

ValofLit (ErrorPat)  *  NullRec; 

ValofLit7 (char  C) : 

ValofLit (Lit (C) )  -  RecofChar (C) ; 

Valof Li t8 ; 

ValofLit (NullPat)  *  NullRec; 

ValofLit9 (Pattern  A,  Pattern  B)  : 
ValofLit (ConcPats (A, B) )  * 
if  IsNullPat (A) 
then  ValofLit (B) 
else  if  IsNullPat (B) 
then  ValofLit(A) 
else  NullRec; 


IsNullPatl : 

IsNullPat (Arb)  *  false; 
l3NullPat2: 

IsNullPat (Bol)  -  false; 

IsNullPat3 (Record  R) : 

IsNullPat (Choice (R) )  ■  false; 
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IsNullPat4 : 

IsNullPat (Closure)  *  false; 
IsNullPat5: 

IsNullPat (Eol)  *  false; 

IsNullPat6 : 

IsNullPat (ErrorPat)  *  false; 

IsNullPat7 (char  C) : 

IsNullPatTLTt(C) )  *  false; 

IsNullPat8: 

IsNullPat (NullPat)  *  true; 

IsNullPat9 (Pattern  A,  Pattern  B) : 
IsNullPat (ConcPats (A, B) )  - 

(IsNullPat (A)  .and.  IsNullPat (B) ) ; 


PirstPatl: 

FirstPat (Arb)  -  Arb; 

FirstPat2; 

FirstPat (Bol)  -  Bol; 

FirstPat3 (Record  R) : 

FirstPat (Choice (R) )  *  Choice (R) ; 

FirstPat4 j 

FirstPat (Closure)  -  Closure; 
FirstPatS: 

FirstPat (Eol)  »  Eol; 

FirstPat6: 

FirstPat (ErrorPat)  ■  ErrorPat; 

FirstPat7 (char  C) : 

FirstPatTLit(C) )  »  Lit(C) ; 


FirstPat8: 

FirstPat (NullPat)  ■  NullPat; 

FirstPat9 (Pattern  A,  Pattern  B) : 

Fir stPat (ConcPats (A, B)  )  ■ 
if  IsErrorPat (A)  .or.  IsEr rorPat (B) 
th*n  ErrorPat 
else  if  IsNullPat (A) 
then  FirstPat (B) 
else  FirstPat (A) ; 


1 
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LastPatl: 

LastPat(Arb)  ■  Arb; 

LastPat2 : 

LastPat(Bol)  *  Bol ; 

LastPat3 (Record  R) : 

LastPat (Choice (R) )  *  Choice (R) ? 

LastPat4 : 

LastPat (Closure)  *  Closure; 

LastPatS: 

LastPat (Eol)  *  Eol; 

LastPatS; 

LastPat (ErrorPat)  3  ErrorPat; 

LastPat7 (char  C) : 

LastPatTlTt (C) )  -  Lit (C) ; 

LastPat8 ; 

LastPat (NullPat)  3  NullPat; 

LastPatB (Pattern  A,  Pattern  B) : 

LastPat (ConcPats (A, B) )  = 

if  IsEr rorPat (A)  .or.  IsEr rorPat (B) 
then  ErrorPat 
else  if  IsNullPat (B) 
then  LastPat (A) 
else  LastPat (B) ; 


RestofPatl: 

RestofPat (Arb)  3  NullPat; 
Restof Pat2 ; 

RestofPat (Bol)  3  NullPat; 

Restof Pat3 (Record  R) ; 

RestofPat (Choice (R) )  3 
if  IsErrorPat (Choice (R) ) 
then  ErrorPat 
else  NullPat; 

RestofPat4: 

RestofPat (Closure)  3  NullPat; 
Restof PatS ; 

Restof Pat (Eol)  3  NullPat; 


Appendix  IV  -  Specifications  from  the  case  study 


Restof Pat6 : 

Restof Pat (ErrorPat)  ■  ErrorPat; 

RestofPat7 (char  C) : 

Restof Pat (Lit (C) )  -NullPat; 

Restof Pat8 : 

Restof Pat (NullPat)  "NullPat; 

RestofPat9 (Pattern  A,  Pattern  B) : 

Restof Pat (ConcPats (A, B) )  ■ 

if  IsEr rorPat (A)  .0£.  IsEr rorPat (B) 
then  ErrorPat 
else  if  IsNullPat(A) 
then  Restof Pat (B) 
else  ConcPats (Restof Pat (A) ,B) ; 


AllButLastPatl : 

AllButLastPat ( Arb)  *  NullPat; 

AllButLastPat2 : 

AllButLastPat (Bol)  =  NullPat; 

AllButLastPat3 (Record  R) ; 

AllButLastPat (Choice (R) )  * 
if  IsErrorPat (Choice (R) ) 
then  ErrorPat 
else  NullPat; 

AllButLastPat4 : 

AllButLastPat (Closure)  ■  NullPat; 

AllButLastPatS; 

AllButLastPat (Eol)  3  NullPat; 

AllButLastPatS ; 

AllButLastPat (ErrorPat)  *  ErrorPat; 

AllButLastPat7 (char  C) : 

AllButLastPatlLlt (C) )  -NullPat; 

AllButLastPat3 : 

AllButLastPat (NullPat)  -  NullPat; 

AllButLastPat9 (Pattern  A,  Pattern  B) : 
AllButLastPat (ConcPats (A, B) )  * 

if  IsErrorPat (A)  .or.  IsEr rorPat (B) 
then  ErrorPat 
else  if  IsNullPat(B) 
then  AllButLastPat (A) 
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else  ConcPats (A, AllSutLastPat (B) ) ; 


ConcPatsl (Pattern  P) : 

ConcPats (NullPat,P)  =  P; 

ConcPats2 (Pattern  P)  : 

ConcPats (P,NullPat)  *  P; 

ConcPats3 (Pattern  P) : 

ConcPats (ErrorPat, P)  =  ErrorPat? 

ConcPats4 (Pattern  P) : 

ConcPats (P, ErrorPat)  *  ErrorPat; 

/+  eject  +/ 

/*  Now,  these  are  the  really  interesting  axioms!  */ 


PatfromRecl (Record  R) ; 

Patf romRec (R)  » 

if  RecordEqual (R,NullRec) 
then  NullPat 

else  /*  there's  something  there!  */ 
if  CharofRec (R)  * 
then 

if  RecLength(R)  =  1 

then  ErrorPat  /*  no  escaped  char  present  V 
else  ConcPats (Lit (CharofRec (Rest (R) ) ) , 
PatfromRec(SubRec(R, 3,1000) ) ) 
else  /*  not  a  literal!  */ 

If  CharofRec (R)  = 

then  ConcPats (Arb, PatfromRec (Rest (R) ) ) 
else  /*  not  an  arb!  */ 

If  CharofRec (R)  * 

then  ConcPats (Closure , 

PatfromRec (Rest (R) ) ) 
else  /*  not  a  closure!  */ 

If  CharofRec (R)  « 
then  ConcPats (Bol , 

PatfromRec (Rest (R) ) ) 
else  /*  not  a  bol!  */ 

If  CharofRec (R)  =  "$" 
then 

ConcPats (Eol , PatfromRec (Rest (R)  ) ) 
else  /*  not  eol!  */ 

If  CharofRec (R)  »  "[" 
then  /*  try  a  choice!  */ 

ConcPats (Choice (SubRec (R, 1 , 

EscapedFind (R,"] ","@") ) >  , 

PatfromRec (SubRec (R, 

EscapedFind (R, ”Q") +1,1000) ) ) 
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else  /*  isn't  a  choice  */ 

ConcPats {Lit (CharofRec (R) ) , PatFromRec (Rest (R) ) ) ; 


PatternEquall (Pattern  A,  Pattern  B)  : 

PatternEqual (A, B)  * 
ijf  IsNullPat  (A) 
then  IsNullPat (B) 
else  if  IsEr rorPat (A) 
then  IsEr rorPat (B) 

else  if  IsNullPat(B)  .or.  IsEr rorPat (B) 
then  false 

else  if  .not.  IsNullPat (Restof Pat (A) )  .or . 

. not .  IsNullPat (Restof Pat (B) ) 
then  7*  not  both  primitive  patterns,  try  again!  */ 
PatternEqual (FirstPat (A) ,FirstPat (B) )  . and . 

PatternEqual (RestofPat (A) , Restof Pat (B) ) 
else  if  IsArb(A)  /*  we  have  primitive  oatterns!  */ 
then  IsArb(B) 
else  if  IsBol(A) 
then  IsBol(B) 
else  if  IsChoice(A) 

then  IsChoice(B)  .and. 

RecordEqual (ValofChoice (A) , ValofChoice (B) ) 
else  if  IsClosure(A) 
tTTen  IsClosure(B) 
else  if  IsEol(A) 
then  IsEol (B) 
else  if  isLit(A) 

then  IsLit(B)  .and . 

RecordEqual (ValofLit (A) ,ValofLit (B) ) 

else 

/*  'A'  MUST  BE  a  "neg  choice"!  The  next  line  is  unneeded 
*  IsNegChoice (A)  .and. 

*/ 

IsNegChoice (B)  .and. 

RecordEqual (ValofChoice (A) , ValofChoice (B) ) ; 


MatchPatl (Record  R,  Pattern  P) : 

MatchPat (R, P)  * 

if  IsNullPat(P)  /*  Is  this  a  Null  pattern  */ 
then  1  /*  a  Null  pattern  always  matches  */ 
else  if  IsEr rorPat (P)  /*  is  this  an  error  pattern  V 
then  0  /*  error  patterns  never  match  */ 
else  if  IsEol (Fir stPat (P) )  /*  is  this  end  of  line  */ 
then  /*  End  of  Line  Dattern  */ 

IT  IsNull(R)  .and.  IsNullPat (Restof Pat (P) ) 

then  /*  we're  at  end  of  the  record  and  pattern!  */ 

else  /*  try  sliding  over!  */ 
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if  MatchPat (Rest(R) ,P)  <>  0 

/*  if  it  matches,  P  *  Eol !  V 
then  MatchPat (Rest (R) , Eol )  +  1  /*  slide!  */ 
else  0  /*  can't  slide  either!  */ 
else  if  IsBol(FirstPat(P) )  /*  is  this  a  BOL  */ 

then  /*  this  pattern  may  not  float  across  the  line!  */ 

Tf  (.not.  IsBol (FirstPat (Restof Pat (P) ) ) )  . and . 

MatchPat (R,RestofPat (?) )  =1 
then  1 
else  0 

else  i f  IsClosure (FirstPat (P) )  /*  is  it  closure  */ 
then  0  /*  pattern  starts  with  closure,  an  error!  */ 
else  if  IsArb (FirstPat (?) )  /*  is  it  an  Arb  */ 
then  /*  this  is  an  Arb  Pattern!  */ 
if  IsClosure (FirstPat (Restof Pat ( P ) ) ) 
then  /*  need  to  handle  closures!  */ 

Tf  IsBol (FirstPat (Restof Pat (RestofPat (P) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 

Tf  IsNull (R)  .or.  MatchPat (Rest (R) ,P)  =  0 
then  /*  Dont  skip  over  the  current  char!  */ 
MatchPat (R, RestofPat (RestofPat (P)  )  ) 
else  1  /*  matched  later,  arbs  start  here  */ 
else  /*  no  closure  hanging  around!  */ 

if  IsBol (FirstPat (RestofPat (P) ) )  .or.  IsNull (R) 

.or .  MatchPat (Rest ( R) , Restof Pat (P) )  =  0 
then  0  /*  can't  match  off  anv  chars  or  float!  */ 
else  /*  o.k.,  see  where  the  rest  floats  to  */ 
MatchPat (Rest (R) , Restof Pat (P) ) 
else  if  IsLit (Fir stPat (P) )  /*  is  this  a  Lit  */ 
then  /*  this  is  an  Lit  Pattern!  */ 
if  IsClosure (FirstPat (Restof Pat (P) ) ) 
then  /*  need  to  handle  closures!  */ 

TT  IsBol (FirstPat (RestofPat (RestofPat (P) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 

Tf  IsNull (R)  .or.  MatchPat (Rest (R) , P)  *  0 

then  /*  no  cKance  of  matching  further  on!  */ 
/*  try  matching  zero  chars  */ 

MatchPat (R, RestofPat (RestofPat (P) ) ) 
else  /*  see  where  the  match  worked  */ 
if  (CharofRec (Valof Lit (Fir stPat {?)))<> 
CharofRec(R)  .and. 

MatchPat  (R,  Restof  Pat  (RestofPat  (P)  )  )  =»1) 
.or .  (MatchPat (Rest (R) , P)  *  1  .and. 
CharofRec (Valof Lit (FirstPat (P) ) ) * 
CharofRec (R) ) 

then  1  /*  did  not  slide  V 
else  /*  did  slide!  It  matchs  later  */ 
MatchPat (Rest (R) ,P)  +  1 
else  /*  no  closure  hanging  around!  */ 
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if  IsNull(R)  .or.  IsBol (Fir stPat (Restof Pat (P) ) ) 
then  0  /*  carT^t  match  off  anv  chars  or  float!  */ 
else  /*  o.k. ,  check  the  first  char  and  then, 
the  rest  of  the  pattern  */ 
i f  Charof Rec (ValofLit(FirstPat(P) ) )* 
CharofRec(R)  .and . 

MatchPat (Rest (R) , Restof Pat  (?) )  =  1 
then  1  /*  we  match  starting  here!  */ 
else  /*  try  floating  across  */ 

IT  MatchPat  (Rest  (R)  ,P)  <  0 

then  MatchPat (Rest (R) ,P)  +  1 
else  0 

/*  Only  legal  patterns  can  be  created,  so  assume: 

*  else 

*  _if  IsNegChoice (FirstPat (P)  )  .or  . 

*  IsChoice (FirstPat (P)  )  /*  choice  */ 

*  then  /*  this  is  an  choice  Pattern!  */ 

V 

else  if  IsClosure (FirstPat (RestofPat (P) ) ) 
then  /*  need  to  handle  closures!  */ 

if  IsBol (FirstPat (RestofPat (RestofPat (P) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 
if  ( .not.  IsNull (R)  .and. 

( (MatchRec(ValofChoice (FirstPat (P) ) , 

First (R) ) <>0)  = 

IsChoice (FirstPat (P) ) )  .and . 

MatchPat (Rest (R) ,P)  3  1)  .or. 

MatchPat (R, Restof Pat (Restof Pat (P) ) )  =  1 
then  1  /*  Match  starts  here!  */ 
else  /*  Current  char  is  not  o.k.,  see  if  it 
matches  later  on  */ 
i_f  MatchPat  (Rest  (R)  ,P)  <>  0 
then  /*  It  does!  */ 

MatchPat (Rest (R) ,P)  +  1 
else  /*  It  does  not!  */ 

0 

else  /*  no  closure  hanging  around!  */ 

if  IsNull (R)  .or.  IsBol (Fir stPat (Restof Pat (P) ) ) 
then  0  /*  carTT  match  off  any  chars  or  float!  */ 
else  /*  o.k.,  drop  the  first  char  and  pattern  */ 
i_f  MatchPat  (Rest  (R)  , Restof  Pat  (P) )  *  1  .and . 
(MatchRec (Valof Choice (Fir stPat (P) ) , 

First(R))  <>  0)  *  IsChoice (Fir stPat (P) ) 
then  1  /*  we  match  starting  here!  */ 
else  /*  trv  floating  across  */ 

IT  MatchPat (Rest (R) ,P)  <>  0 
then  MatchPat (Rest (R) , P)  +  1 
else  0 

/*  not  needed,  because  ALL  oatterns  ARE  viable! 

*  else  0  /*  not  a  viable  pattern  V 
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V 

;  /*  end  of  axiom!  */ 


MatchLenl (Record  R,  Pattern  P) : 

MatchLen (R, P)  * 
i f  IsNull(R)  .or. 

IsNullPat(P)  /*  Null  records  and  Null  patterns  */ 
then  0  /*  alwavs  have  nothing  left  to  match!  */ 
else  if  IsEr rorPat (P)  /*  is  this  an  error  pattern  */ 
then  0  /*  error  patterns  never  match  */ 
else  if  IsEol (FirstPat (P) )  /*  is  this  end  of  line  */ 
tfien  0  /*  EOL  pattern  allows  nothing  to  follow  */ 
else  if  IsBol (FirstPat (P) )  /*  is  this  a  BOL  */ 

then  /*  this  pattern  may  not  float  across  the  line!  */ 
if  (.not.  IsBol (Fir stPat (Restof Pat (P) )) ) 

.and.  MatchPat (R, Restof Pat (P)  )  *  1 
then  MatchLen(R, RestofPat (P) )  /*Match  starts  here!*/ 
else  0 

else  if  IsClosure (FirstPat (P) )  /*  is  it  closure  */ 
then  0  /*  pattern  starts  with  closure,  an  error!  */ 
else  if  IsArb (FirstPat (P) )  /*  is  it  an  Arb  */ 
then  /*  this  is  an  Arb  Pattern!  */ 

Tf  IsClosure (FirstPat (Restof Pat (P) ) ) 
then  /*  need  to  handle  closures!  */ 

if  IsBol (FirstPat (RestofPat (RestofPat (?) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 

Tf  MatchPat (Rest (R) , P)  *  0 

then  /*  Dont  skip  over  the  current  char!  */ 
MatchLen (R, Restof Pat (Restof Pat (P) ) ) 
else 

MatchLen(Rest (R) ,P)  +  1  /*  match  here  */ 
else  /*  no  closure  hanging  around!  */ 
if  IsBol (Fir stPat (Restof Pat  (P) ) ) 

.or .  MatchPat (Rest (R) , Restof Pat (P) )  *  0 
then  0  /*  can't  match  off  any  chars  or  float!  */ 
else  /*  o.k.,  counting  the  current  char  */ 
MatchLen (Rest (R) , Restof Pat (P) )  +  1 
else  if  IsLit (FirstPat (P) )  /*  is  this  a  Lit  */ 
then  /*  this  is  an  Lit  Pattern!  */ 

Tf  IsClosure (FirstPat (RestofPat (P) ) ) 
then  /*  need  to  handle  closures!  */ 

TF  IsBol (FirstPat (Restof Pat (Restof Pat (P) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 
if  MatchPat (Rest (R) ,P)  *  0 

then  /*  no  chance  of  matching  further  on!  */ 
/*  try  matching  zero  chars  */ 

MatchLen (R, Restof Pat (RestofPat (P) ) ) 
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else  /*  see  where  the  match  worked  */ 

IT  CharofRec (ValofLit (Fir stPat (P) ) ) <> 
CharofRec(R)  .and. 

MatchPat (R, Restof Pat (Restof Pat (P) ) ) =1 
then  /*  stopped  matching  of  the  lits!  */ 
MatchLen(R,RestofPat(RestofPat(P) ) ) 
else  /*  see  if  we  start  matching  here  */ 
Tf  MatchPat (Rest (R) ,P)  =  1  .and . 

CharofRec (ValofLit (Fir stPat (P) ) ) 
CharofRec (R) 
then  /*  didn't  slide  */ 

MatchLen (Rest (R) ,P)+1 
else  /*  Didn't  start  match  here!  */ 
MatchLen (Rest (R) ,P) 
else  /*  no  closure  hanging  around!  */ 
if  IsBol (Fir stPat (Restof Pat (P) ) ) 
then  0  /*  can't  match  off  any  chars  or  float!  */ 
else  /*  o.k.,  check  the  first  char  and  then, 
the  rest  of  the  pattern  */ 
if  CharofRec (ValofLit (Fir stPat (P) ) )= 

CharofRec (R)  .and. 

MatchPat (Rest (R) , Restof Pat (P) )  *  1 
then  /*  we  match  starting  here!  */ 

MatchLen (Rest (R) , Restof Pat (P) )  +  1 
else  /*  try  floating  across  */ 
i_f  MatchPat  (Rest  (R)  ,P)  <>  0 
then  MatchLen (Rest (R) ,P) 
else  0 

/*  only  legal  patterns  can  be  created,  so  this  is  assumed: 

*  else 

*  Tf  IsNegChoice (Fir stPat (P) )  .or. 

*  IsChoice (FirstPat (P) )  /*  choice  */ 

*  then  /*  this  is  an  choice  Pattern!  */ 

V 

else  if  IsClosure (Fir stPat (Restof Pat (P) ) ) 
then  /*  need  to  handle  closures!  */ 

I?  IsBol (FirstPat (Restof Pat (Restof Pat (P) ) ) ) 
then  0  /*  Can't  match  next  Bol  */ 
else  /*  no  Bols  hanging  around!  */ 

T?  ( (MatchRec (ValofChoice (FirstPat (P) ) , 

First(R) ) <>0) “IsChoice (FirstPat (P) ) )  .and. 
MatchPat  (Rest  (R)  ,P)  =*  1 
then  /*  this  char  starts  it!  */ 

MatchLen(Rest(R) ,P)  +  1 
else  /*  Does  not  start  at  this  char...  */ 
i^f  MatchPat  (R,RestofPat  (RestofPat  (P)  ) )  =  1 
then  /*  It  really  matchs  starting  here  */ 
MatchLen (R, Restof Pat (Restof Pat (P) ) ) 
else  /*  Current  char  is  not  o.k.,  see  if  it 
matches  later  on  */ 
if  MatchPat (Rest (R) ,P)  <>  0 
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then  /*  It  does!  */ 

Matchlen (Rest (R) ,P) 
else  /*  It  does  not!  */ 

else  /*  no  closure  hanging  around!  */ 
if  IsBol (FirstPat (Restof Pat (P) ) ) 

then  0  /*  can't  match  off  anv  chars  or  float!  */ 
else  /*  o.k.,  drop  the  first  char  and  pattern  */ 
T?  MatchPat (Rest (R) , Restof Pat (P) )  3  I  .and. 
(MatchRec{ValofChoice (FirstPat (P) ) , 
First(R))  <>  0)  *  IsChoice (FirstPat (P) ) 
then  /*  we  match  starting  here!  */ 

MatchLen (Rest (R) /Rest jf Pat (P) )  +  1 
else  /*  try  floating  across  */ 

MatchLen (Rest (R) /P) 

/*  not  needed,  because  ALL  patterns  ARE  viable! 

*  else  0  /*  not  a  viable  pattern  */ 

*/ 

;  /*  end  of  axiom!  */ 
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ljL.4.  Axioms  for  the  Editor 

Editor  1 (Files  Text,  Files  Commands): 

Editor (Text, Commands)  * 
if  IsEmpty (Commands) 
then  Text 

else  if  . not .  AtTop (Back (Commands) ) 

tKen "Editor (Text , Delete (Back (Commands) ) ) 
else  if  At Top (Commands) 

tKen  /*  need  to  point  to  first  record!  */ 

Editor (Text,Advance(Commands) ) 
else  if  FirstisA (Cur rentRec (Commands ),"," ) 

then  /*  EditlAddr  won't  be  able  to  detect  the  error!  */ 
Editor (Text, Delete (Commands) )  /*  ignore  the  error  */ 
else  /*  first  see  if  there  is  a  target  address  */ 

Editor (EditlAddr (Text, 

SkipAddr (Cur rentRec (Commands ) ) , 

AddrfromCommand (Text ,CurrentRec (Commands) ) ) , 

Advance (Delete (Commands) ) ) ; 


AddrfromCommandl (Files  Text,  Record  Command): 

AddrfromCommand (Text, Command)  * 
if  FirstisDigit (Command) 

then  /*  first  address  is  line  number  */ 

IntvalofRec (Command) 
else  if  FirstisA (Command, " . ") 

then  /*  first  address  is  the  current  line!  */ 
CurrentAddress (Text) 
else  if  FirstisA(Command, "/") 

tKen  /*  first  address  is  a  search  forward  */ 

Tf  EscaoedFind (Rest (Command) "@")  <>  0 
then  /*  first  address  is  from  a  search!  */ 
ForwardSearch(Text , 

PatfromRec (SubRec (Command , 2 , 

EscapedFind (Rest (Command) , "/" , ) -1) ) ) 
else  /*  search  specifier  is  messed  up  */ 
CurrentAddress (Text) 
else  if  FirstisA (Command , " 

then  /*  first  address  is  a  search  backward  */ 

^  EscapedFind (Rest (Command) , " 

then  /*  first  address  is  from  a  search!  */ 

BackwardSearch (Text , PatfromRec (SubRec (Command, 2 , 
EscapedFind (Rest (Command) ," 
else  /*  search  specifier  is  messed  up  */ 
CurrentAddress (Text) 
else  if  FirstisA (Command, "$") 

then  /*  first  address  is  end  of  text  file  */ 
FTlesLength (Text) 

else  CurrentAddress (Text) ;  /*  fail  safe  */ 
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SkipAddrl (Record  Command): 

SkipAddr (Command)  * 
if  FirstisDigit (Command) 

then  /*  address  is  line  number  */ 

SubRec ( Command, MatchPat (Command, 

PatfromRec (Recof Str ing {*  pO-9] ") ) ) ,1000) 
else  if  FirstisA(Command, " . M)  .or. 

FiTstisA (Command, "$") 

then  /*  address  is  the  current  line  or  end  of  file  */ 
Rest (Command) 

else  if  FirstisA(Command, "/")  .or . 

FlrstisA (Command, " 
then  /*  address  is  a  search  */ 

IT  EscapedFind (Rest (Command) , 

CharofRec (Command) , )  <>  0 
then  /*  address  is  a  search  */ 

SubRec (Command, EscapedFind (Rest (Command) , 
CharofRec (Command) , ) +2 , 1000) 

else 

NullRec 

else  Command;  /*  No  Address  present???  */ 


EditlAddrl (Files  Text,  Record  Command,  int  Address): 
EditlAddr (Text, Command, Address)  * 
if  FirstisA(Command, " , ") 

then  /*  need  to  peel  off  the  next  address  V 
EditApply (Goto (Text , Address) , 

SkipAddr (Rest (Command) ) , 

AddrfromCommand (Text , Rest (Command) ) -Address  +  1) 
else  EditApply (Goto(Text, Address) , Command,!) ; 


EditApplyl (Files  Text,  Record  Command,  int  Count): 

EditApply (Text , Command, Count)  ■ 
i f  Count  <=»  0 

then  Pr intCurrent (Text) 

else  if  IsNull (Command)  .0£.  FirstisA(Command, "p") 
then  /*  need  to  watch  the  count  */ 
if  Count  >  1 
then 

ETitApoly (Advance (Pr intCurrent (Text) ) , 

Command, Count  -  1) 
else  Pr intCurrent (Text) 
else  if  FirstlsA(Command, "d") 

EditApply (Advance (Delete (Text) ) ,RecofChar ("d") , Count-1) 
else  if  FirstisAfCommand, "s") 
then 
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if  Escapedfind (Rest (Rest (Command) ) , 

CharofRec (Rest (Command) ) ,”@")  <>  0  .and . 

/*  middle  delimiter  V 
EscapedFind ( SubRec (Command , 

EscapedFind (Rest (Rest (Command) ) , 

CharofRec(Rest (Command) ) , "@n) +3 , 

/*  was  '+1',  found  via  */ 

/*  expression  monitoring  */ 

1000) , CharofRec (Rest (Command) ) , ) <>0 
/*  ending  delimiter  */ 
then  /*  both  delimiters  present  */ 
if  Count  >  1 
then 

EditApply (Advance(ApplySubstitute (Text, 
PatfromRec (SubRec (Command , 3 , 

EscapedFind (Rest (Rest (Command) ) , 

CharofRec (Rest (Command) ) , B@") -1) ) , 

SubRec (Command , 

EscapedFind (Rest (Rest (Command)  ) , 
CharofRec (Rest (Command) ) ,  "@") +3, 
EscapedFind (SubRec (Command, 

EscapedFind (Rest (Rest (Command)  ) 
CharofRec (Rest (Command) ) ,"§") 
+3,1000) , 

CharofRec (Rest (Command) ) , 
"@") -1) ) )  , 

Command , Count- 1) 

else  /*  don't  advance!  */ 

Pr intCurrent (ApplySubstitute (Text , PatfromRec ( 
SubRec (Command , 3 ,EscapedFind (Rest (Rest ( 

Command)) , CharofRec (Rest (Command) ) ,"@")-l) ) 
SubRec (Command , EscapedFind (Rest (Rest ( 
Command) ) , 

CharofRec(Rest (Command) ) ,"@")+3, 
EscapedFind (SubRec (Command, 

EscapedFind (Rest (Rest (Command) ) , 
CharofRec (Rest (Command) ) , "®" ) 
+3,1000) , 

CharofRec (Rest (Command) ) , 
"fl")-l' ) ) 

else  /*  missing  delimeter???  */ 

/*  Apply  no  changes!  */ 

EditApply (Text ,Recof String ('s/ //') , Count) 
else  if  FirstisA(Command,"i'')  /*  try  for  an  insert  */ 
then  /*  It  is  insert!  */ 

T?  Count  >  1 

then  /*  Advance  between  insertions!  */ 

EditAoply (Advance(Insert(Rest(Command) ,Text) ) , 
Command , Count- 1 ) 

else  /*  don't  advance  the  last  time!  */ 
PrintCurrent(Insert(Rest(Command) ,Text) ) 
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else  /*  no  editor  command  present???  */ 

EditApply (Text, Command, 0) ;  /*  at  least  cause  the  printl  */ 


ApplySubstitutel (Files  Text,  Pattern  P,  Record  R) : 
ADolySubstitute(Text,P,R)  » 
if  IsErrorPat (P)  .or. 

AtTop(Text)  .or . 

MatchPat (Cur rentRec (Text) ,P)=0 
then  Text 
else 

Replace (ConCatRec (ConCatRec ( 

SubRec (Cur rentRec (Text ) , 1 , MatchPat ( 

CurrentRec (Text) ,P)-1) ,R) ,SubRec( 

Cur rentRec (Text) , MatchPat (Cur rentRec (Text ) , P) + 
MatchLen (CurrentRec (Text) ,P) ,1000) ) ,Text) ; 


BackwardSearchl (Files  Text,  Pattern  P) : 
BackwardSearch(Text,P)  * 
if  AtTop(Back (Text) ) 

then  0  /*  NO  WRAPAROUND!  */ 
else 

IT  MatchPat (CurrentRec(Back (Text)  ) ,P)  <>  0 
then  Cur rentAddress (Back (Text)  ) 
else  BackwardSearch(Back (Text) ,P) ; 


ForwardSearchl (Files  Text,  Pattern  P) : 

ForwardSearch (Text ,P)  = 
if  AtEnd(Text) 

then  FilesLength (Text) 
else 

IT  MatchPat (CurrentRec (Advance (Text) ), P)  <>  0 
then  Cur rentAddress (Advance (Text) ) 
else  ForwardSearch (Advance (Text) ,P) ; 
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